PCT 



WORLD INTELLECTUAL PROPERTY ORGANIZATION 
mtcrnational Bureau 




INTERNATIONAL APPLICATION PUBLISHED UNDER THE PATENT COOPERATION TREATY (PCI) 



(51) Internationa] Patent Classification 6 : 
G06F 17/00, 17/30 



Al 



(11) Internationa] Publication Number: WO 98/38583 

(43) International Publication Date: 3 September 1998 (03.09.98) 



(21) Internationa] Application Number: PCT/US98/03S73 

(22) Internationa] Filing Date: 24 February 1998 (240198) 



(30) Priority Data: 
60/039,813 



26 February 1997 (26\0Z97) US 



(63) Related by Continuation (CON) or Continuation-m-Part 
(CIP) to Earlier Application 

US 60/039313 (CON) 

Filed on 26 February 1997 (26.02.97) 



(71) Applicant (for all designated Slates except US): SIEBEL 

SYSTEMS, INC [US/USJ; 18SS South Grant Street San 
Mateo, CA 94402 (US). 

(72) Inventors; and 

(75) Inventors/Applicants (for US onfyy. BRODERSEN, Robert 
A. [US/US}; 17 Spinaker Drive, Redwood City, CA 94065 
(US). UM, Peter, S. (US/TJSJ; 917 Governors Bay Drive, 
Redwood City, CA 94065 (US). 

(74) Agents: GOLDMAN, Richard, M.; Cootey Godward LLP, 
3000 El Camino Real, Five Palo Alto Square, Palo Alto, 
CA 94306-2155 (US) etaL 



(81) Designated States: AL, AM, AT, AU, AZ, BA, BB, BG, BR, 
BY, CA, CH, CN, CU, CZ, DE, DK, EE, ES, FI, GB, GE, 
GH, GW, HU. ID, IL, IS, JP. KE, KG, KP, KR, KZ, LC, 
LK, LR, LS, LT, LU, LV, MD, MG, MK, MN, MW, MX, 
NO, NZ, PL, PT, RO, RU, SD, SE, SG, SI, SK, SL, TJ, TM, 
TR, TT, UA, UG, US, UZ, VN, YU, ZW, ARIPO patent 
(GH, GM, KE, LS, MW, SD, SZ, UG, ZW), Eurasian patent 
(AM, AZ, BY, KG, KZ, MD, RU, 17, TM), European patent 
(AT, BE, CH. DE, DK, ES, FI, FR, GB, GR, IE, IT, LU, 
MC, NL, PT, SE), OAPI patent (BF, BJ, GP. CG. CI, CM, 
GA, GN, ML, MR, NE, SN, TO, TG)l 



Published 

With international search report. 

Before the expiration of the time limit for amending the 
claims and to be republished in the event of the receipt of 
amendments. 



(54) Title: METHOD OF DETERMINING VISIBILITY TO A REMOTE DATABASE CLIENT OF A PLURALITY OF DATABASE 
TRANSACTIONS HAVING VARIABLE VISIBILITY STRENGTHS 




(57) Abstract 

The invention relates to a method of managing a database. The database includes a central database (3) and separate partially 
replicated databases (23-a, 23-b, 23-c). Each partially replicated database resides in a separate node (21 -a, 21-b, 21 -c). Each replicated 
d at abase has an associated visibility strength. The method of managing a database determines the visibility strength of a partially replicated 
database to data being-propagated, determines therefrom the visibility of the partially replicated database to the data being propagated, and 
propagates the data to a partially replicated database only if the node of the partially replicated databa se has visibility to the data. 



BEST AVAILABLE COPY 



FOR THE PURPOSES OP INFORMATION ONLY 
Codes used to identify States party to the PCT on the front pages of pamphlets publishing international applications under the PCT. 



AJU 


Albania 


BS 


Spam 


LS 


Lcvotho 


Si 


Slovenia 


AM 


Armenia 


PI 


Hamad 


LT 




SK 


Slovakia 


AT 


Austria 


FR 


Prance 


Ul 


Lnxomboarg 


SN 




AU 


Aostndxi 


GA 


Gabon 


LV 


Latrfa 


SZ 


Swaziland 


AZ 


Amtwljan 


CB 


United Kfa^doro 


' MC 


Mooaco 


TD 


Chad 


BA 


BmjJi and Herzegovina 


GS 


Georgia 


MD 


^ ■ ■ i fcitt M S Hill, - 

nryuuia* of MOUDwa 


TG 


Togo 


B8 


Barbados 


GH 


OlSB 


MG 


Mait&nrjr 


TJ 


Tajflttaa* 


BE 




CN 


Guinea 


MK . 


Tbe formci Yngpi fay 


TM 




BF 


Barkm Fkso 


GR 


Greece 




wiaana; Of raaccoonia 


TR 


Tarkcy 


BG 


Bnbnrti 


HU 




ML 


MaH 


TT 


TlUikLh) aadlbhajp 


BJ 




IS 


Ireland 


MM 


Mongolia 


UA 




BR 


Bnxfl 


IL 


brae) 


MR 




UG 


Uganda 


BY 


BctSTDS 


IS 


Iceland 


MW 


Malawi 


US 


Uaked States of America 


CA 


Canada 


IT 


Italy 


MX 


Mab 


UZ 


Uzbeltatsn 


CP 


Centra] African Republic 


JP 


Kenan 


NB 


Niger 


VN 


Viet Nam 


CG 


Congo 


KE 


Kenya 


NL 


Ndtaciliads 


YD 


Yugoslavia 


CB 




KG 


Kyrgymn 


NO 




ZW 


Zimbabwe 


a 


C&te dfvoso 


KP 


Denocntjc foople's 


NZ 


KcVzlaland 






CM 






Rrpoblc or* Korea - 


PL 


Foliod 






CN 


Qriaa 


KR 




PT 


foftsga) 






CD 


Cuba 


KZ 


Kauejiao 


RO 


Romania 






CZ 




LC 


Saint Locia 


RU 


Rosuaa federation 






Dg 


Germany 


U 




SD 


Socxn 






DK 


Dcnnark 


LK 


Sri Lanka 


SB 


Sweden 






EB 




LR 


Liberia 


SG 


Srflgipcue 







'WO 9808583 PCT/US98/03573 



METHOD OF DETERMINING VISIBILITY TO A REMOTE DATABASE 
CLIENT OF A PLURALITY OF DATABASE TRANSACTIONS HAVING 
VARIABLE VISIBILITY STRENGTHS 

5 

INTRODUCTION 

LTghnicM Field 

This invention relates to a system and method for providing updates to a network of 
10 partially replicated relational database systems, and, more particularly, for providing 
an efficient means for computing the visibility to a client on the network of a 
transaction processed against the database. 

IL Background 

15 Relational databases are a commonly-employed data structure for representing 

data in a business or other environment A relational database represents data in the 
form of a collection of two-dimensional tables. Each table comprises a series of cells 
arranged in rows and columns. Typically, a row in a table represents a particular 
observation. A column represents either a data field or a pointer to a row in another 

20 table. 

For example, a d ataba se describing an organizational structure may have one 
table to describe each position in the organization, and another table to describe each 
employee in the organization. The employee table may include information specific 

25 to the employee, such as name, employee number, age, salary, etc. The position 
table may include information specific to the position, such as the position title 
("salesman", "vice president", etc.), a salary range, and the like. The tables may be 
related by, for example, providing in each row of the employee table a pointer to a 
particular row in the position table, coordinated so that, for each row in the employee 

30 table, there is a pointer to the particular row in the position table that describes that 
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employee's position. A relational database management system (RDBMS) supports 
"joining 0 these tables in response to a query from a user, so that the user making a 
quay about, for example, a particular employee, may be provided with a report of 
the selected employee, including not only the information in the employee table, but 
5 also the information in the related position table. 

Relational databases may be much more complex than this example, with 
several tables and a multiplicity of relations among them. 

10 With the widespread use of inexpensive portable computers, it is advantageous 

to replicate a database onto a portable computer for reference at locations remote 
from the central computer. The replicated database may then be referenced by the 
user of the portable computer, without requiring reference to the main database, 
which may be maintained at a central location inconvenient to the user of the portable 

IS computer. However, there are a number of difficulties with the use of a replicated 
database ■ 

(tee disadvantage is that a full copy of the central database may require more 
data storage than is desired or economical. For example, a salesman working in the 

20 field may need to refer to the database for information regarding sales opportunities 
in his sales area, but have no need to refer to any information regarding sales 
opportunities outside of his area. One possible approach to reduce the amount of 
required data storage is to simply replicate only that portion of the database that is 
needed by the user. However, this approach does not recognize that the criteria to 

25 determine which portions of the data are required is likely to vary over time. For 
example, the salesman may have a new city added to his territory. Under 
conventional approaches, the salesman would need to re-replicate his local copy of 
the database, this time selecting data including the added city. Such a practice is 
inconvenient, subject to error, and time-consuming. 

30 

A further disadvantage to a replicated database is the difficulties encountered 
in attempting to update data using the replicated copy. A change made to the 
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replicated database is not made to the central database, leading to a discrepancy 
between the information that is stored in the replicated copy of the database and the 
information that is stored in the central database. Although it is possible to journal 
modifications made to the replicated copy and apply an identical modification to the 
5 central database, one problem that this approach fiaces is the possibility of colliding 
updates; that is, where a user of a replicated copy makes a change to data that is also 
changed by a user of the central copy or by the user of another replicated copy. 

It is therefore desirable to provide a capability to maintain one or more 
10 partially-replicated copies of a central database, in such a way that the degree of 
replication may be easily changed without requiring a refresh of the entire replicated 
database, and that permits updates to be coordinated among users of the central 
rtfftaKaw and users of the partially replicated databases. 

15 SUMMARY Qf TgE 

The present invention is directed to a method of maintaining a partially 
replicated database in such a way that updates made to a central database, or to 
another partially replicated database, are selectively propagated to the partially 
replicated database. Updates are propagated to a partially replicated database if the 

20 owner of the partially replicated database is deemed to have visibility to the data 
being updated. Visibility is determined by use of predetermined rules stored in a 
rules database. In one aspect of the invention, the stored rules are assessed against 
data content of various tables that make up a logical entity, known as a docking 
object, that is being updated. 

25 

In another aspect of the invention, the stored rules are assessed against data 
content of one or more docking objects that are not necessarily updated, but that ate 
related to a docking object being updated. In one embodiment, the visibility attributes 
of die related docking objects are recursively determined. 

30 

In yet another aspect of die invention, changes in visibility are determined to 
enable the central computer to direct die nodes to insert the docking object into its 
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partially replicated database. Such changes in visibility are determined so as to 
enable the central computer to direct a node to remove a docking object from its 
partially replicated database. 

S In a further aspect of the invention, the predetermined rules are in declarative 

form and specify visibility of data based upon structure of the data without reference 
to data content* 

In still another aspect of the invention, the transactions made to the database 
10 are ordered and processed in such a way as to reduce the computational resources 
required to calculate the visibility of the transactions. 

In still another aspect of the invention, the transactions made to the database 
are ordered and processed using a cache in such a way as to reduce the computational 
IS resources required to calculate the visibility of the transactions. 

In still another aspect of the invention, database objects and transactions have 
an ?«nrtoM visibility strength used to determine the visibility of a transaction to an 
object 

20 

In still another aspect of die invention, die visibility calculations are performed 
using a amplified set of rules located in a central dictionary. 

TOTKF mgSf MPTTON OF THE DRAWINGS 
25 Figure 1 depicts an overview of die operation of one embodiment of the 

present invention. 

Figure 2 depicts a database schema that shows die relationship of the various 
compo nen ts dot make up a Docking Object 

30 

Figure 3 depicts steps performed by an update manager to update a database. 
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Figure 4 depicts steps performed by a Docking Manager to transmit and/or 
receive one or more transaction logs. 

Figure 5 depicts the steps performed by a mage processor to merge 
5 transaction log records into an existing database. 

Figure 6 depicts the steps performed by a log manager to prepare a partial 
transaction log. 

10 Figure 7 depicts the steps performed by a viability calculator for calculating 

visibility for a docking object as invoked by a lag manager. 

Figure 8 depicts the steps performed to synchronize a partially replicated 
database in response to a change in data visibility. 
IS Figure 9 depicts the structure of the database design of the transaction log 

table. 

Figure 10 depicts a database diagram for the central dictionary. 
DESCRIPTION OF SPECIFIC EM BODIMENTS 

20 Qv^rvfew 

Figure 1 depicts an overview of the operation of one embodiment of the 
present invention. Figure 1 de p i c ts a central computer system 1 and three remote 
computer systems (or "nodes") 21-a, 21-b, and 21 -c. Each of nodes 21-a, 21-b and 
21-c are depicted in various states of communication with central computer system 
25 1, as win be more fully explained* Central computer system 1 includes a central 
database 3 , a docking manager 5 , a merge processor 7 and a log manager 9 . Central 
c ompute r system 1 additionally optimally includes update manager 11 responsive to 
user input 13. 

30 Node 21-a is a remote computer system, such as a mobile client such as a 

laptop computer. Node 21-a includes a partially replicated remote database 23-a, 
update manager 31-a responsive to user input 33-a, docking manager 25-a ami merge 
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manager 27-a. In operation, update manager is responsive to user input 33-a to make 
changes to remote database 23-a as directed by the operator of node 21 -a. Updates 
made are recorded, orjournaled, in node update tog 35-a. 

5 At some point at the convenience of the operator of node 21-a, node docking 

manager 35-a is activated, and enters into communication with central docking 
manager S. Update log 35-a is taken as input by node docking manager 25-a, and 
provided to central docking manager 5. Central docking manager 5 creates a received 
node update log 19, which contains all the information that had been recorded in 
10 update log 35-a. Optionally, partial log 17-a is taken as input by central docking 
manager 5 and provided to node docking manager 25-a, as more fully described 
herein. 

At some point in time, at die convenience of the operator of central computer 
15 system 1, mage processor 7 is activated. Merge processor 7 Cakes as input received 
node update log 19, and applies the updates described therein to central database 3. 
In the process of applying the updates from received node update log 19, merge 
processor journals the updates applied to central update log 15. Optionally, update 
manager 11, responsive to user input 12 makes additional changed to central database 
20 3 as directed by the operator of central computer system 1. The updates made by 
update manager 11 are additionally jouroaled in central update log 15. 

At some point in time, at the convenience of the operator of central computer 
system 1, log manager 9 is activated. Log manager 9 takes as input central update 

25 log 15 and produces as output a set of partial logs 17-a, 17-b and 17-c according to 
visibility rules as will be further described herein. Each of partial togs 17-a, 17-b 
and 17-c corresponds to ok of nodes 21-a, 21-b and 21-c. When a node docking 
manager such as node docking manager 25-a enters into communication with central 
docking manager 5 and optionally requests transmission of hs corresponding partial 

30 log, central docking manager 5 takes as input the appropriate partial log, such as 
partial log 17-a, and presents it to node docking manager 25-a. Node docking 
manager 25-a then replicates partial log 17-a as merge log 37-a. 
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At some point in die future, at the convenience of the operator of node 21 -a, 
merge processor 27-a is activated. Merge processor 27-a takes as input merge log 
37-a, and applies die updates described therein to partially replicated database 23-a. 

5 In addition to node 21-a, Figure 1 also depicts two additional nodes 21-b and 

21-c. Node 21-b is depicted in communication with central computer 1. However, 
unlike node 21-a, the operator of node 21-b has requested only to send his updates 
to central computer system 1, and has not requested to be presented with changes 
made elsewhere to be made to his partially replicated database 23-b. This may be, 

10 for example, if the operator has an urgent update that must be made as soon as 
possible, but does not have the time to receive updates from other nodes. 
Accordingly, Figure 1 shows only transmission of node update log 35-a from node 
docking manager 25-bto central docking manager 5 , and no transmission from central 
docking manager 5 to node docking manager 25-b. Accordingly, the merge manager 

IS for node 21-b is not activated and is not shown. 

Likewise, node 21-c is depicted as not in communication with central 
computer system 1. Accordingly, the docking manager for node 21-c is not activated 
and is not shown. 

20 

By the cycle described above, updates made by each of nodes 21-a, 21-b and 
21-c are presented to central computer system 1, permitting central data hare 3 to be 
updated accordingly. In addition, each of the updates made by each of the nodes 21- 
a, 21-b and 21-c, as well as updates made on central computer system 1, are routed 
25 bade to each of nodes 21-a, 21-b, and 21-c, thereby keeping each of partial databases 
23-a, 23-b and 23-c in synchronization with each other and with central database 3. 

Database ftrwftpre 

The synchronization of central database 3 with node databases 23-a, 23-b and 
30 23-c is performed using a construct called a Docking Object A Docking Object 
consists of Member Tables (including one Primary T&ble), Visibility Rules, Visibility 
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Events, and related Docking Objects. Each docking object has a visibility level and 
visibility level attributer as will be described more fully herein below. 

A Member Table is a table of the relational database that makes up a docking 
5 object When a docking object is propagated from central database 3 to one of node 
databases 23-a, 23-b or 23-c, the propagation takes the form of an insertion into each 
of the Member Tables associated with the particular docking object. Similarly, when 
f a docking object is scheduled to be removed from a database, that removal consists 
of deleting records from the member tables associated with the docking object. For 
10 example, a docking object that represents a sales opportunity may include tables that 
represent the opportunity itself (e.g., named "SjOFTY"), the product whose sale is 
represented by the opportunity (e.g., named 'SOPTY^PROD") , the contact for the 
opportunity (e.g., named "S_OPTY_CONTACT*), etc. Each of these tables is said 
to be a member table of the "Opportunity Docking Object/ In an additional aspect 
IS of hte invention, each member table row can have one or more rows that correspond 
to the docking object 

A Primary Table is a Member Table that controls whether a particular instance 
of a Docking Object is visible to a particular node. The Primary Table has a Primary 
20 Row-ID value that is used to identify a row of the Primary Table being updated, 
deleted or inserted For example, the "Opportunity Docking Object" may have as a 
primary table the table S OPTY. The row-id of that table, i.e., S OPTY.row id, is 
the Primary Row-ID for the Opportunity Docking Object 

25 Each dock object has a visibility level and a visibility level attribute that are 

analyzed using visibility rules. The valid values are 'Enterprise*, 'Limited' and 
'Private.* AH member table rows in an enterprise dock object are replicated to any 
nodes. Member table rows in limited dock objects are replicated to any nodes. 
Member table rows in limited dock objects are subject to viability checks and are 

30 routed to nodes that have visibility to the rows. A Visibility Rule is a criterion that 
determines whether a particular instance of a Docking Object is "viable* to a 
particular node 21. If a Docking Object is visible to a particular node, that node will 



-8- 



* 

WO 98/38583 



PCT/US98/03573 



receive updates for data in the Docking Object Visibility Rules are of two types, 
depending on the field RULBJTYFE. A Visibility Rule with a RULEJTYPE of "R" 
is referred to as an SQL Rule* An SQL Rule includes a set of Structured Query 
Language (SQL) statements that is evaluated to determine if any data meeting the 
5 criteria specified in the SQL statements exists in the Docking Object If so, the 
Docking Object is visible to the node. A Visibility Rule with a RULEJTYPE of *0" 
is referred to as a Docking Object Rule. A Docking Object Rule specifies another 
Docking Object to be queried for visibility. If the specified Docking Object is 
visible, then the Docking Object pointing to it is also visible* 

10 

A Related Docking Object is a Docking Object that is propagated or deleted 
when the Docking Object under consideration is propagated or deleted. For example, 
an Opportunity Docking Object may have related Docking Objects representing die 
sales contacts, the organizations, the products to be sold, and the activities needed to 
IS pursue the opportunity. When an Opportunity Docking Object is propagated from 
Central Database 3 to one of node databases 23, die related docking objects are also 
propagated. 

Figure 2 depicts a database schema that shows the relationship of the various 
20 components that make up a Docking Object* The schema is a meta-database, in that 
it does not describe the data being accessed in the database. Rather, the schema is 
a separate database that defines the structure of the database being accessed. That is, 
it is a database comprising tables that describe the relationships and data contexts of 
another database. 

25 

Each of the tables shown in Figure 2 is a table in a relational database, and 
as such is in row-column form. Many columns represent fields that are common to 
all the illustrated tables. Such fields include for example, a ROWJD to identify a 
particular row in the table, as well as fields to track the date and time that a row was 
30 created and last modified, and the identity of the user who created or modified the 
row. In addition, each table contains fields specific to that table, ami which are 
described in detail below. 
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Table S_DOBI 61 describes the Docking Objects in an application. Table 
SJXffiJ 61 includes the fields OBJ NAMB and FRIMARYTABLEJD. Field 
OBJ_NAMB defines the name of the Docking Object being described. Field 
PRIMARY JTAELBJD is used to identify the primary table associated with this 
5 Docking Object 

Table S_DOBJ JNST 63 describes w hether a particular instance of a Docking 
Object, described by table SJX)BJ 61, is present on a particular node's database. 
Table SJDOBJJNST 63 includes the fields NODEJD, DOBJJD and 
10 PR_TBL_ROW JD. Held NODEJD points to a particular node table 65. Field 
DOBJJD points to the Doddng Object to which the Docking Object instance applies. 
Field PRTBLROW JD is used to select a particular row in the Primary Table of 
the Docking Object. This value identifies the Docking Object instance. 

IS Table S_KEL_DOBJ 67 describes the related Docking Objects of a particular 

Doddng Object, described by table SJXffiJ 61. Table S_RELDGBJ 67 indudes 
the fields DOBJJD, WELJX3BJJD, and SQLSTATEMENT. Field DOBJJD 
identifies the Doddng Object dm owns a particular related Docking Object. Field 
RELJDOBJJD identifies the related Docking Object that is owned by the Docking 

20 Object identified by DOBJJD. Field SQL STATEMENT is an SQL statement that 
may be executed to obtain the Primary ID value of the related Docking Object 

Table S_DOBJJIBL 69 describes the member tables of a particular Docking 
Object, described by table SJX>BJ 6L Table SJDOBJJIBL 69 includes the fields 

25 DOBJJD, TBLJD, and VBJ3VENTFLG. Field DOBJJD identifies the Docking 
Object that contains the member table described by the row . Field TBLJD identifies 
the particular table in the database that is the member table described by the row. 
Field VBJBVENTjrLG is a flag that indicates whether a change to this Doddng 
Object can result in a visibility event. A value of "Y" indicates that a change can 

30 result in a visibility event; a value of "N* indicates that it cannot 
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Table SJDOBJVE_RULE 71 contains the viability rules associated with a 
particular Docking Object SJX)BJJVE_RULB 71 contains the fields DOBJJD, 
RULHSEQUENCE, RULETYFE, SQLSTATEMENT and CHECK.DOBJJD. 
Field DOBJID identifies the Docking Object with which a particular visibility rule 
5 is associated Held RULB_SEQUENCB is a sequence number that indicates the 
sequence, relative to other visibility rules in table SJDOBJ_VIS_jRULB 71, in which 
the particular visibility rule should be run. RUUBJTYPE specifies whether the 
particular visibility rule is of type *R," indicating an SQL visibility mle or of type 
"O," indicating a Docking Object visibility rule. 

10 

If RULE TYPE is equal to "R," field CHECK JDCffiJJD is not meaningful, 
and field SQL_STATEMENT contains an SQL statement that is evaluated using the 
Primary ROW-ID of the primary table associated with this Docking Object and a 
particular Node 21. If the SQL statement returns any records, the Docking Object 
IS is deemed to be visible to the Node 21 for which visibility is being determined. 

If RUUBJTYFE is equal to "O/ both field CHECK JX>BJJED and field 
SQL STATEMENT are meaningful. Field OTECK_DOBJJD specifies a docking 
object whose visibility should be determined. If the specified docking object is 
20 deemed to be visible, then the docking object associated with the visibility rule is also 
visible. Field SQL STATEMENT contains a SQL statement that, when executed, 
returns the Row-ID of the docking object identified by CHBCKDOBJID that 
corresponds to the docking object instance associated with the visibility rule. 

25 Table S_APP_TBL 73 b an Application Table that describes all the tables used 

in a particular application. It is pointed to by table S_DOBJ_TBL 69 for each 
member table in a docking object, and by table S_DOBJ for the primary table in a 
docking object. S_APPTBL~73 points to table S_APP_COL 75, winch is an 
Application Column Table that describes the columns of data in a particular 

30 application. S_AFP_TBL 73 points to table S_AFP_COL 75 directly through a 
primary key and indirectly through such means as a Foreign Key Column Table 81, 
User Key Column Table 83, and Column Group Table 85. The relationship of an 
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Application Table, Application Column Tbble, Foreign Key Column Table, User Key 
Column Table and Column Group Table are well known in the art and are not further 

described. 

5 Update Processing 

Figure 3 depicts steps performed by an update manager 31 such as update 
manager 31-a,3l-b or 31-c in updating a database, such as a node database 23-a, 23- 
b or 23-c, responsive to user input Execution of update manager 31 begins in step 
101. In step 103, the update manager 31 accepts from the user input 33 in the form 

10 of a command requesting that the data in database 23 be altered. The request may 
be in die form of a request to delete a row of a table, to add a row to a table, or to 
change the value of a cell at a particular column of a particular row in a table. In 
step 105, using a well-known means, the update manager 31 applies the requested 
update to database 23. In step 107, the update manager 31 creates a log record 

IS describing the update and writes it to update log 35. 

The contents of a log record describe the update made. Each log record 
indicates the node identifier of the node making die update, an identification of the 
table being updated, and an identification of the type of update being made, Le., an 

20 insertion of a new row, a deletion of an existing row, or an update to an existing 
row. For an insertion, the log record additionally includes an identifier of the row 
being inserted, including its primary key and the values of the other columns in the 
row. For a deletion, the log record identifies the primary key of the row being 
deleted. For an update, the log record identifies the primary key of the row being 

25 updated, the column within the row being updated, the old value of the cell at die 
addressed row and column, and the new value of the cell. 

After writing a log record in step 107, the update processor exits for this 
update. The foregoing description of the update processing preferably includes 
30 additional steps not material to the present invention, for example, to assure 
authorization of the user to make the update, to stage and commit the write to the 



-12- 



I * 

WO 98/38583 



PCT/US98/03573 



database to allow for rollback in the event of software or hardware failure, and the 
like. These steps are well-known in the ait and are not described further. 

An update manager 11 executing in central computer system 1 operates in an 
5 analogous manner, except that it updates central database 3 and writes its log records 
to central update log 11. 

nuking TN^rrenng 

Figure 4 depicts steps performed by a Docking Manager 25 such as Docking 

10 Manager 25-a, 25-b or 25-c to transmit and/or receive one or more transaction logs. 
Docking Manager 25 is invoked by the user of a remote node such as node 21-a, 21-b 
or 21-c, whereby the user requests that the node dock with central computer 1 to 
upload an update log such as update log 35-a to central computer 1, to download a 
partial log such as partial log 17-a, or both. Execution of Docking Manager 25 

15 begins in step 12L Instep 123, Docking Manager 25 connects with central computer 
1 under the control of Central Docking Manager 5. This connection can be any 
connection that enables data exchange. It is anticipated that the most common form 
of a connection is a telephone line used in conjunction with a modem, but other forms 
of data connection, such as a Local Area Network or a TCP/IP connection may also 

20 be used. Step 125 checks to see whether the user has requested that node update log 
35-a be uploaded to the Central Computer 1 . If so, execution proceeds to step 127. 
If not, step 127 is dapped and control is given to step 129. In step 127, Docking 
Manager 25 uploads its update log to central co mpute r 1. The upload may be 
accomplished with any known file transfer means, such as XMODEM, ZMODEM, 

25 KERMTT, FTP, ASCD transfer, or any other method of transmitting data. In step 
129, Docking Manager 25 checks to see whether the user has requested that a partial 
log such as partial log 17-a be downloaded from Central Computer 1. If so, execution 
proceeds to step 131. If not, step 131 is skipped and control is given to step 133. 
In step 131, Docking Manager 25 downloads its partial log from central computer 

30 1. The download may be accomplished with any known file transfer means, such as 
XMODEM, ZMODEM, KERMTT, FTP, ASCII transfer, or any other method of 
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transmitting data. In &ep 133, having completed the requested data transfer, Docking 
Manager 25 exits* 

Merge Processing 

5 Merge processing is performed by a processor such as node merge processor 

27-a, 27-b, or 27-c, or central meige processor 7. Hie merge process serves to 
. update its associated *fatahagft with a transaction that has been entered by a user of a 
computer remote from the computer where merge processing is being performed. 
Merge processing is analogous to update processing and is similar in form to update 

10 processing as previously disclosed with reference to figure 3, with three differences. 
First, die input to a merge processor is not an update entered directly by a user, but 
rather is a log file that is obtained from a computer remote from the computer where 
die merge is executing. A second difference is thai, as shown by in Figure 1, merge 
processing does not produce a log when performed at a node. The function of a log 

IS on a node is to record a transaction for propagation to Central Computer system 1 
and thence to other nodes as required. A transaction that is the subject of a mage 
in a node has been communicated to Central Computer System 1, and there is no 
need to re-communicate it. 

20 A third difference is that merge processing must be capable of detecting and 

resolving multiple conflicting transactions. For example, assume that a field contains 
the value "Keith Palmer." Assume further that a user at node 27-a enters a 
transaction to update that field to "Carl Lake/ and a user at node 27-b enters a 
transaction to update the same field to "Greg Emerson." Without collision detection, 

25 data among various nodes may become corrupt When the transaction for user 27-a 
is merged, the field is updated from "Keith Palmer" to "Carl Lake." Without 
collision handling, when the transaction for node 27-b is merged, the field would be 
updated to "Greg Emerson/ and the central database would then be out of synch with 
the database of node 27-a. Furthermore, when merge processing is performed on 

30 each of nodes 27-a and 27-b, each node will update its database with the other's 
transactions, leaving at least one node out of synch with die other node and with 
central database. 
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Therefore, merge processing must also have a means of detecting collisions 
and correcting them. In the above example, a simple way to detect and correct a 
collision is to compare the value in the database to the value that the merge log 
reflects as being the previous value in the node database. If the two values do not 

5 match, Merge processor 7 may reject the transaction and generate a corrective 
transaction to be sent to the node from which the conflicting transaction originated. 
In the above example, when the transaction for node 27-b was presented to merge 
processor 7, merge processor 7 would compare "Keith Palmer/ the prior value of 
the field as recorded by node 27-b to "Carl Lake/ die present value of the field as 

10 recorded in central database 3. Detecting the mismatch, merge pr ocessor 7 may then 
generate a transaction to change the value "Greg Emerson" to "Carl Lake/ and write 
that transaction to update log 15. 

The above is one example of a collision and a resulting corrective action. 
IS Other types of collisions include, for example, an update to a row that has previously 
been deleted, insetting a row that has previously been inserted, and the like. Merge 
processing must detect and correct each of these collisions. This may be performed 
using any of a number of well-known methods, and is not discussed further. 

Figure 5 depicts the steps performed by merge processor such as central merge 
processor 7. Although it depicts merge processor 7 writing to central database 3 and 
to transaction tog 15, it is equally representative of a node merge processor such as 
node merge processor 27-a, 27-b or 27-c updating a node database 23-a, 23-b or 23- 
c. Merge processing begins at step 141. In step 143, merge processor 7 finds the 
first unprocessed transaction on received log 19. In step 147, merge processor 7 
selects a transaction from received log 19. In step 149, merge processor 149 attempts 
to update database 3 according to the transaction selected in step 147. In step 151, 
merge processor 7 determines whether die database update of step 149 failed due to 
a collision. If so, merge processor proceeds to step 153, which generates a corrective 
transaction. Following the generation of die corrective transaction, the merge 
processor returns to step 149 ami again attempts to update database 3. If no collision 
was detected in step 151, execution proceeds to step 157. In step 157, merge 
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processing checks to see if h is executing on central computer 1. If so, step 155 is 
executed to journal the transaction to log 15. In any case, either if step 157 
determines that the merge processing is being performed on a node or after step 155, 
execution proceeds to step 159. Step 159 checks to see if any transactions remain to 
5 be processed from log 19. If so, execution repeats from step 147, where the next 
transaction is selected. If not, merge processing exits in step 161. 

Log Management 

Figure 6 depicts the steps to be performed by log manager 9 to prepare a 

10 partial transaction log such as partial transaction log 17-a, 17-b, or 17-c. The 
procedure depicted in Figure 6 is executed for each node available to dock with 
central computer system 1. Log manager 9 begins execution in step 171. Instep 
173, Log Manager 9 finds the first unprocessed transaction for the node whose partial 
transaction log is being prepared. In step 175, log manager 9 selects a transaction 

15 for processing. In step 177, log manager 9 checks to see whether the selected 
transaction originated on the same node for which processing is being performed. If 
so, these is no need to route the transaction back to the node, and control proceeds 
to step 179. Step 179 checks to see whether there are any transactions remaining to 
be processed. If so, control is given again to step 175. If not, control passes to step 

20 189, which records the last transaction that was processed for this node, and then 
exits at step 191. If die transaction originates in other than the same node as the node 
for which processing is being performed, control is given to step 181 . Step 181 calls 
a visibility calculator to determine whether the selected transaction is viable to the 
node being processed. The Visibility calculator routine is described in detail farther 

25 herein. In step 183, log manager 9 checks to see whether die visibility calculator 
determined that the transaction is visible. If it is not visible, control is passed to step 
179, which performs as disclosed above. If the transaction is viable, control is 
passed to step 185. Step 185 writes a record for this transaction to die partial 
transaction log for the node being processed, for example, partial transaction log 17-a 

30 for node 21-a. In step 187, the log manager 9 records the last transaction that was 
processed for this node, and then passes control to step 179, which determines 
whether to select additional transactions or exit, as disclosed above. 
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Visibility Calculation 

Figure 7 depicts a flowchart describing the process a visibility calculator for 
rainiiattng visibility for a docking object as invoked by step 181 of log manager 9. 
The viability calculator is called with the nod&-id of the node for which visibility is 

5 being calculated, the docking object for which the visibility is being calculated, and 
the row-id of the docking object whose visibility id being calculated. Hie visibility 
calculator uses this information, in conjunction with information obtained from meta- 
data stored in the schema depicted in Figure 2, to determine whether a particular 
transaction that updates a particular row of a particular docking object is visible to 

10 a particular node. 

The Visibility calculator begins execution at step 201. In step 203, the 
visibility calculator makes a default finding that the transaction is not viable. 
Therefore, unless the viability calculator determines that a transaction is visible, it 
15 will exit with a finding of no visibility. In step 205, the viability calculator selects 
the first visibility rule associated with the docking object. This is done by finding the 
table SJDOBJJVTS_RULB71 associated with the current Docking Object as pointed 
to by table S_DOBJ 61. In step 205, the visibility calculator selects the row of table 
SJX)BJ_VIS_RULE 71 with the lowest value for field RULE_SEQUENCR 

20 

In step 207 „ the Viability Calculator checks the field RUUETYPE for a value 
ofR." The value of *R" indicates that the rule is a SQL visibility rule. If so, the 
Viability Calculator proceeds to step 209. In step 209 the Visibility Calculator 
obtains a SQL statement from field SQL_STATEMENT and executes iL An example 
25 of such an SQL statement might be: 



SELECT 'X' FROM S_OFIY_EMP 
WHERE OPTY ID = iPrimaiyRowId 
AND EMPJD = rNoddd; 

30 

This SQL statement causes a query to be made of application table 
SjOPIY_EMP. The queiy selects any records meeting two criteria. First, the 
records selected must have a field OPFYJD, which is a row id or key, equal to the 
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Primary How-ID of the Docking Object whose visibility is being determined. 
Second, the records selected must have a field HMPJED, which may be for example, 
an identifier of a particular employee, equal to the Nodeld of the node for whom 
visibility is being determined In ordinary language, this SQL statement will return 
5 records only if a row is found in a table that matches employees to opportunities, 
where the opportunity is equal to the one being updated, and the employee to whom 
the opportunity is assigned is the operator of the node. 

This is a simplistic example, provided for maximum comprehension. More 

10 complex SQL statements are possible. For example, the rule: 

SELECT *X' FROM 
&Table_OwnCT.S_ACCT_POSTN ap 
&Table_Owner.S_EMP_POSTN ep 
WHERE ap.PGSniONJD = ep.POSmONJD 
15 AND epJBMPID = :NodeM; 

This rule queries the tables S_ACCTPQSTN (which relates a particular 
account with a particular position in die organization that is responsible for the 

20 account) and S_EMP_POSTN (which relates what employee corresponds to a 
particular position). The condition "ap.POSmONJD » ep.POSmONJD" requires 
finding a row in the account-to-position table that has the same position as a row in 
the employee-to^osition table. The condition "ep.EMPJD = rNodeEd" further 
requires that the selected row in the employee-to-position table also have an Employee 

25 ID equal to the ID of die user of the Node for which visibility is being determined. 
In ordinary language, this condition allows visibility if the employee occupies the 
position that has responsibility for the account in the docking object being updated. 

These is no particular limit to the complexity of the conditions in the SQL 
30 statement used to evaluate visibility. Particular implementations of SQL may impose 
itmHflrinnQ and resource considerations may make it desirable to use less complex 
statements, but these limitations are not inherent in the invention. 
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Step 211 evaluates whether the execution of SQL_STATEMENT in step 209 
returned any records. If records were returned, this indicates that the Node for which 
visibility is being checked has visibility to the docking object being processed. 
Accordingly, if records are returned, the Visibility Calculator proceeds to step 213. 

5 In step 213, die transaction is marked visible. Because no further rules need to be 
evaluated to determine visibility, the visibility calculator proceeds to step 228. Step 
228 synchronizes die databases by determining whether the calculated visibility 
requires the insertion or deletion of a docking object into a particular node's partially 
replicated database. This may occur, for example, if a node is determined to have 

10 visibility to a docking object due to a change to a related docking object For 
example, an owner of a node may be assigned to a particular activity that is related 
to a particular sales opportunity. As a result, the node should be provided with a 
copy of the object representing the sales opportunity. 

IS Figure 8 depicts the steps performed to synchronize a partially replicated 

rtatahare in response to a change in data visibility. Execution begins in step 241. In 
step 243, the Visibility Calculator references the visibility just calculated for a 
docking object If the Docking Object is visible, execution proceeds to step 245. 
Step 245 references the S_DOBJ_INST table, to verify that a row exists for the 

20 Docking Object for the current node. If a row exists, this indicates that die node in 
question already has a copy of the referenced Docking Object, and die routine 
proceeds to step 255, where it exits. If, however, no row exists for the Docking 
Object at die node being processes, this indicates that die node in question does not 
have a copy of the Docking Object on its partially replicated database. The routine 

25 then proceeds to step 247, where a transaction is generated to direct the node to insert 
the Docking Object into its partially replicated database. 

If step 243 determines that the Docking Object is not visible, execution 
proceeds to step 249. Step 249 references die S JX)BJJNST table, to verify that no 
30 row exists for die Docking Object for the current node. If step 243 determines that 
no row exists in the S_DOBJ_INST table for the current docking object for the 
current row, this indicates, that die node in question does not have a copy of the 
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referenced Docking Object, and the routine proceeds to step 255, where it exits. If, 
however, a row exists for the Docking Object at the node being processed, this 
indicates that the node in question does have a copy of the Docking Object on its 
partially replicated database. Hie routine then proceeds to step 251, where a 
5 transaction is generated to direct the node to delete the Docking Object from its 
partially replicated database. 

Referring again to Figure 7, following the data synchronization routine of step 
228, the Visibility Calculator proceeds to step 229, where it exits. Referring to 
10 Figure 6, as previously described, the resulting finding of viability is available to be 
checked by the log manager in step 183 to determine to write the transaction. 

Referring again to figure 7, if step 211 determines that no records were 
returned by the execution of the SQL statement in step 209, execution proceeds with 
IS step 215. Step 215 checks to see whether there are any remaining visibility rules to 
be assessed. If not, the visibility calculator proceeds to step 228 to synchronize the 
database, and then to step 229, where it exits. In this case, the default mark of no 
visibility that was set in step 203 remains set. This value will also be used by the log 
manager as shown in Figure 6, step 183, to determine not to write the transaction. 

20 

Referring again to Figure 7, if rules remain to be assessed, control proceeds 
to step 217, which selects the next rule to be processed. Control is then given again 
to step 207 to begin processing the new rule. 

25 The preceding text provided a description of the processing or SQL visibility 

rule; that is, visibility rules of type "R." If step 207 determines that the visibility rule 
is not of type "R," the visibility rule is of type "O." Type "O" indicates a docking- 
object visibility rule. In such a case, the docking object being processed will be 
considered to be visible if it is related to a particular related docking object that is 

30 viable. If field RULE TYPE is not equal to "R," then, execution proceeds to step 
221. Step 221 determines the related Docking Object whose viability must be 
determined to determine whether the current docking object is viable. The related 



-20- 



' WO 98/33583 



PCT/US98/03573 



Docking Object identifier is obtained from field CHECK_DOBJJD in table 
S_DOBJ_VIS_RXJLB7L In step 223 , the Visibility Calculator determines which row 
in the related Docking Object must be queried for visibility. In order to determine 
this, the Visibility Calculator obtains a predetermined SQL statement from the field 
5 SQL_STATEMENT and executes it The SQL statement is a query that select one 
or more rows of the Docking Object that, for example, correspond to the docking 
object for which the Visibility Calculator was invoked. 

For example, asspwie that it is desired to indicate that a record for a sales 

10 opportunity should be visible if the Node has visibility to any sales quote made for 

that sales opportunity . This may be accomplished using the following SQL statement: 

SELECT "ROWJD" FROM 

&Table_OwMT.S_DOC_QUOTE 
WHERE OPTYJD = rPrimary Rowld 

15 

This SQL statement accesses a table S_DOC_QUOTE that contains all sales 
quotes. The WHERE clause specifies retrieval of all rows where the Opportunity ID 
of the row is equal to the Row-ID of the opportunity for which visibility is being 
20 calculated. The Visibility manager retrieves the specified Row-Ids, thereby 
identifying the rows of the S_DOC_QUOTE table whose visibility must checked 

Having determined the a related docking object and the row-ID of that related 
docking object upon whose visibility the visibility of the current docking object 

25 depends, the Visibility Calculator proceeds to step 225. In step 225, the Visibility 
Calculator recursively invokes itself to determine visibility of the related docking 
object The recursively invoked Visibility Calculator operates in the same maimer 
as the Visibility Calculator as called from the Log Manager 9, inducting the capability 
to further recursively invoke itself. When the recursive call concludes, it returns a 

30 visibility indicator for the related Docking Object, and control proceeds to step 227. 
In step 227, the Visibility calculator determines whether the related Docking Object 
was determined to have been visible! If so, the Visibility Calculator proceeds to step 
213 to mark the originally current Docking Object as visible, and then to step 228 to 
synchronize the database and thai to step 229 to exit. If the related Docking Object 
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was not determined to be visible, control proceeds to step 215 to determine whether 
additional visibility rules remain to be assessed. 

The Visibility Calculator, in conjunction with the Log Manager is therefore 
5 able to determine what subset of update transaction data is required to be routed to 
any particular node. This operation saves to reduce the transmission of unneeded 
data from die Central Computer 1 to the various nodes such as nodes 21 -a, 21-b and 
21-c that utilize partially replicated databases, and to reduce the system resources 
such as disk space needed to store, and the CPU time needed to process, what would 
10 otherwise be required to maintain a fully replicated database on each remote node. 

The operation of the log manager 9 in conjunction with the Visibility 
Calculator herein described will be apparent from reference to the description and to 
the drawings. However, as a further aid in the description of these facilities, a 
IS pseudocode representation of these facilities is hereto attached as an Appendix. 

Batch V fcftffi+Y f^nfrtfrffl 

The calculation of visibility events and the routing of visible transactions may 
be optimized by batching related SQL statements, rather than performing successive 

20 row-by-row operations. This optimization is achieved by eliminating redundant 
operations, using set processing and reducing network traffic. Redundant work is 
eliminated by deaormalizing key data used to calculate viability into the transaction 
log. For example, the Log Manager the docking object, primary table id, visibility 
event flags, and related data are stored in the transaction log table. Instead of 

25 calculating this data once for every mobile client, Log Manager calculates this data 
once for all mobile clients to use. Log Manager uses set processing by submitting 
SQL statements to check the visibility of many thousands of transactions 
simultaneously instead of submitting a SQL statement for each transaction. Network 
traffic is reduced by retrieving only the visible transactions from the database server 

30 to the docking server. Consequently, significantly less data travels over the network 
from the database server to the docking server. 



-22- 



W09S73S583 



PCT/US98/03573 



Figure 9 depicts the structure of the database design of the Transaction Log 
Table 300 used to support batch viability checking. Node table 301 is the central 
table of the database, and contains one-tcnnany pointers to Dock Olqect Instance table 
302, Dock Status table 304, and Transaction table 3%. 

5 

Docking Object Instance table 302 stores whether a docking object instance 
is visible to a mobile client and has been downloaded to the mobile client. A row 
exists in Docking Object Instance table 302 if the docking object instance is fully 
viable or partially visible to the mobile client If the docking object is not visible, 
10 then a row for the docking object instance does not appear in Docking Object Instance 
table 302, Docking Object Instance table 302 (SJDOBMNST) comprises the 
following fields to support batch visibility checking: 

NODBJD: a non-null user key of the node to which this docking 
15 object instance relates. 

DOBJJD: a non-null user key of the docking object to which this 
docking object instance relates. 

FR_TBL_ROW_ID: a non-null user key containing the RowJD of the 
primary table in the docking object. This value identifies the Docking Object 
20 Instance. 

STATFlag: a one-byte flag containing the value 'F or TP\ Tbe 
value T* indicates that the docking object instance is fully viable. The value 
*P* indicates that the docking object instance is partially visible. 

LAST_CHKJTXN_ID: the transaction ID of the transaction in which 
25 the visibility of the dock object instance was last checked. This value may be 

used to determine when the dock object instance must be recalculated. For 
example, if LAST^CHKJIXNJD = 3000, then Log Manager should not re- 
calculate visibility of the dock object instance until a visibility event occurs 
after transaction ID 3000. 

30 

Dock Status table 304 stores status information relating to each mobile client. 
This includes the identity of the last file merged, the last file extracted, and the last 
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transaction extracted. Dock Status Table 304 (S_DCK_STAT) comprises the 
following fields to support batch visibility checking: 
ROWJtt): primaiy key. 

NODEJD: Identity of the mobile client that owns this status 
5 information* 

TYPE: This field is used to inteipiet the VAL field, and contains one 
of the strings "EXTRACT_RBCORD" , " LOG_EXTRACT" , 
"MERGERECORD" , "LASTMERGB" , or •SESSION*. 

' VAL: This field contains the value corresponding to die data type in 
10 the TYPE field 

In addition, this table records the last transaction processed by an executable 
program called the Log Preprocessor. This is indicated in the VAL field for a row 
with a ROWJD of zero and a TYPE of "EXTRACTRECORD". 

15 

Transaction table 306 stores transaction that may need to be routed to all 
mobile clients. Transaction table 306 (S JDCK_TXN_LOG) comprises the following 
fields to support batch visibility checking: 

TXNJD: A non-null primary key that identifies the transaction. 
20 DOBJJOD: a non-null user key of the docking object to which this 

docking object instance relates. 

PR_TBL_ROW_ID: a turn-null user key containing the Row _H> of the 
primary table in the docking object. This value identifies the Docking Object 
Instance 

25 VB_EVTJFLG: This field contains either the value TP or 'N\ and 

indicates whether the transaction causes a visibility event 

VISJLEVEL_FLG: This field indicates the visibility level of the dock 
object A value 'L* indicates that the dock object has limited visibility. A 
value of *P' indicates that the dock object is private. A value of *E* indicates 

30 that this object has enterprise visibility. 
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Batch visibility checking executes in four phases. Briefly, Phase 1 is tun one 
for each transaction in Transaction Log Table 300 and denonnaiizes the transaction 
log data into the constituent tables. Phase 2 is run once per mobile client per 
iteration, and checks for visibility events for a mobile client Phase 3 is run once per 
5 mobile client per iteration, and extracts visible transactions for the mobile client 
Phase 4 is run once per iteration and deletes transactions from Transaction Log Table 
300. Detailes of all four phases are described below. 



In an embodiment of the present invention, phases 1 and 4 may be combined 
10 into a single executable program called the Log Preprocessor. Only one Log 
Preprocessor is run against an installation at any one time. Phases 2 and 3 may be 
combined into a single executable program called the Log Router. One or more Log 
Routers may be run against a single installation concurrently. The Log Router 
program may use semaphores to prevent more than one Log Router from routing 
15 transactions to the same mobile client simultaneously. 



Phase 1 is run one for each transaction in Transaction Log Table 300 and 
denonnaiizes the transaction log data into the constituent tables. This phase 
denonnaiizes values in S__DCK_TXN_LOG based on transaction log data. The 
20 following pseudocode describes the operation of Phase 1 in detail: 



DoPhaselO 
{ 

- Get status values so we can identify which txns to pre-process 
25 Get maxfrXNJD) from SJDCXJTXNJjOG 

Get TXNJPROCESSEDJD from S_DCK_STAT for Node id 0 

numTkns :~ 0; 

- SELECT d.* 

30 - FROM S_DCX JEXNJLOG tl 

- WHERE TXNJD > maxfTXN JHROCESSED ID) 

- ANDTXN ID <= maxCIXNJD) 

- ORDER BY TXNJD ASC 

FOR each txn between max(IXNJD) and TXNFROCESSEDJD LOOP 
35 - If the client program already calculated the denormalized 

- columns, then we don't have to do it again. 
IF tl.DOBJJD is not mill THEN 
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continue; 
END IF; 

FOR each operation in the txn LOOP 
5 - Use UTLIdSqlO to get primary table row Jds 

— Assumes that each txn can only have one primary rowjd 
FOR each primary id row LOOP 

IF operation is a visibility event THEN 
p_vis_evtflg : = TP; 
10 ELSE 

p_vis_evt_flg := TT; 
END IF; 

update S_DCK_TXNJLOG 
15 set (DOBJJD, PR TBL ROWJD, VIS_EVTJFLG) 

= (DOBJJD, PRJTBL^ROW ID, p_vis_evtjlg) 
where TXNJD = current txn_id; 
END IF; 
END LOOP; - each operation 
20 oumTxns := numTxns + 1; 

END LOOP; - each txn 

— Commit after every N txns 
IF numTxns > roaxTxns THEN 
25 Set TXNPROCESSED _ID = current TXNJD 

commit; 

numTxns := 0; 

— k>ck the row again 

Get TXNFROCESSEDJD from S_DCK JSTAT for Node id 0 
30 END IF; 

END LOOP; - for loop 



Phase 2 is run once per mobile client per iteration, and checks for viability 
35 events for a mobile client This phase looks for all visibility event transactions and 
recomputes viability. It looks for the next set-based transactions in order to limit the 
current iteration to a reasonable amount of processing. Hie phase downloads and 
removes Docking Obect instannes in response to visibility changes and stores the 
visibility of Docking Object instances.in table S_DOBMNST 63. Hie following 
40 pseudocode describes the operation of Phase 2 in detail* 



ProcessVisibilityEvent (DOBJ ID, FRJTBL ROW JD, STAT FUG) 
{ 

- If we have already calculated viability for this dobj 
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- instance in this iteration, then we do not need to 

- recheck visibility. 

IP already check viability for tikis dobj instance THEN 
return; 
5 END IF; 

- Flush the S_DORJ_INST table cache 
Call UTLN odeDObjlnstFhishO 

10 - Compute viability 

Run SQL rules, Check Dock Object rules. 

- Reconcile SJDGBJJNST table and do downloads/removes as needed 

- If viability has changed, stuff the value of TXN_EROCESSED_ID 
15 - into S_IX)BI.IJ^ST_CHK_TXNJD 

- NOTE: we can also stuff in the value of max(TXNJDD) so we do not 

- download txns affecting the dob} instance until after the 

- current max(TXN_ID) 
Call LOGReconcOeDObpustO 

20 } 

D6Phase2 (NODE ID) 
{ 

- Get status values so we can identify which txns to pre-process 
25 Get VIS_CHECKRECORD from SJDQCJ5TAT 

— new status for vis checks high water mark 
Get TXN_PROCESSEDJD from S_DCK_STAT for Node Id 0 

- Don't do anything if there are no new txns to process 

30 IF TXN_EROCESSED_ID = VE_CHECKJRECORD THEN 
return; 
END IF; 

Open the .dx file for writing 

35 

- Get visibility event txns, and load viability 

- {3M jH» simultaneously 

- SELECT tLTXN ID, tLOPERATION, U.VIS_EVT_FLG, 

tLDOBJJD, tLFRJIBLROWJff), dLSTAT FLG, 
40 - dLLAST CHK TXN ID 

- FROM S DOBJ INST cfi7 

SJ>CkjIXNLOGtl 

- WHERE tLTXN ID > VIS CHECK RECORD 

- AND tLTXN H) < = TXN_PROCESSED_ID 

45 - AND tLTXNJD < = VB_CHECKRECORD + batchjsize 

- (Oracle & Informix) 

- AND (tLOPERATION in (T, V) // set-based txn 

or ti.VE_EVTFLG = *Y*) 
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- AND tt.FR_TBL_ROWJD = dLPRIBL ROWJD (+) 

- AND tLDOBJ ID = di.DOBJJD (+) 

- AND tf.VBJLEVEL_FLG = U /* limited visibility */ 

- AND dLNODE ID (+) = :node_id 

5 - AND TXNJED > di.LAST_CHK TXN ID 

- ORDER BY tl.TXNJD 

- NOTE: on Sybase, use set rowcoimt to limit batch size 

- On Oracle & Informix, we assume that not many TXNJD 

- values arc lost if the db server crashes and restarts. 

10 

mimTxns := 0; 

Set VB_CHBCK_RECORD := old VB_CHECK_RECORD; 
FOR each vis event txn or set-based txn in the batch LOOP 

— We got a set-based txn 

15 ProcessVisibilityEvent (tl.DOBJ ID, 

tt.PR_TBL_ROWJD, di.STATJFLG) 
END IF; 

IF amount written to .dx file > threshold THEN 
20 Close and compress the .dx file 

Increment LOG EXTRACT counter in SJXX_STAT 

Add .dx file to list of files that were written 

(do not write to server.tx file yet) 
END IF; 

25 

Set VE_CHECK_RECORD = cunent_txn_id 
END LOOP; 

30 IF Phase3 is separate program THEN 

— Do this part if Phase 3 is a separate program 

IF txns woe downloaded/removed to the current .dx file THEN 

Close and compress the .dx file 

Increment LOG EXTRACT counter in S JXX_STAT 
35 Add .dx file to list of files that were written 

(do not write to server.tx file yet) 
ELSE 

Delete the .dx file 
END IF 

40 

Write all .dx files to the server.tx file 

— Commit at the end of the batch 
commit; 

45 END IF; 
> 
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Phase 3 is run once per mobile client per iteration, and extracts visible 
transactions for the mobile client. The following pseudocode describes the operation 
of Phase 3 in detail. 



S DoPbase3 (NODE ID) 
{ 

IFPhase2 is a separate program THEN 

Open the ,dx file for writing 
END IF; 

10 

- Get status values so we can identify which txns to extract 
Get VB CHECK RECORD from S JDCKJSTAT 

Get EXTRACTRECORD from S JDCXJSTAT 

15 - SELECT tf.TXNID 

- FROM S_DCK JI7CNJLOG d 

- WHERE U.TXN ID > EXTRACTJRECORD 

- AND tl.TXN E)< = VIS CHECK_RECORD 

- AND (tl.VBJEVT_FLG = Y /* enterprise visible */ 
20 - or (tl. VBJBVTJ5LG = % V f* limited visible */ 

- and ffTFi? ** 

(select 'visible' 

- from SJDORJINST di 

where tLDOBJ_ID = di.DOBJJD 
25 and tLPR_TBL_ROW_ID = di.PR_TBL_ROW ID 

and <fi.NODB_ID = 'node id' 
and U.TXN_K> > di.LAST_CHK_TXN_ID) 

) 

) 

30 - ORDER BY TXNJDASC 
numTxns := 0; 

FOR each visible txn between EXTRACT RECORD and VISCHECK RECORD 
LOOP 

35 Write the txn to the .dx file 

mimTxns : = numTxns + 1; 

IF amount written to .dx file > threshold THEN 
Close and co mpress the .dx file 
40 Increment LOGEXTRACT counter in SDCKSTAT 

Add .dx file to list of files that were written 
(do not write to server.tx file yet) 
END IF; 
END LOOP; 

45 

Set EXTRACTJRECORD = VIS_CHECK_RECORD; 
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IF txns were downloaded/xemoved/written THEN 

Close and compress the .dx file 

Increment LOG_EXTRACT counter in S_DCK_STAT 

Add .dx file to list of files that were written 
5 ELSE 

Delete the .dx file 
END IF 

- Commit at the end of the batch 
10 commit; 

Phase 4 is run once per iteration and deletes obsolete transactions from 
Transaction Log Table 300, including its subsdtuent Transaction table 306 and Set 
Transaction ID table 308. The following pseudocode describes the operation of Phase 
IS 4 in detail. 



DoPhase4 0 
{ 

- Get status values so we can identify which txns to delete 
20 Get max(EXTRACT_RECORD) from S_DCKJSTAT 

Get max(EXTRACT_RECOBD) from last iteration 

- No new txns to delete 

IF max(EXTRACT_RECORD) = last iteration THEN 
25 return; 
END IF; 

- DELETE FROM S JXX JIXNLOG 

- WHERE TXN_ID"< = max(EXTRACT RECORD) 
30 Delete from SJXXTXNJjOG 

- Commit at the end of the batch 
commit; 

35 

Improved performance may be obtained by providing a capability of caching 
recent visibility events* The S JDOBJJNST table 63 is particularly suitable to 
provide such a "visibility cache." The existence of a particular docking object 
40 instance in SJX)BJJNST table 63 may be used to assert that the docking object 
instance is visible to the mobile client. 
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The visibility cache improves performance in two ways. First, it reduces the 
number of times visibility must be calculated. Log Manager 9 can use the cache in 
memory to determine visibility of a docking object instance when the transaction is 
on a table that does not cause implicit visibility events (i.e. the 
5 VIS1BILJIY_EVTJFLG is not checked for the table). Log Manager does not need 
to run any visibility SQL statements to determine the visibility of the transaction. 
Note that, if a transaction affects a table that can cause a visibility event, Log 
Manager must re-run the visibility SQL statements to determine that transaction's 
. visibility. 

10 

Second, the visibility cache reduces the number of SQL statements executed 
per visibility calculation. Log Manager uses the cache to determine visibility of check 
docking objects. Log Manager does not need to recursively run visibility rule SQL 
statements on each check docking object instance to determine the visibility of the 
IS transaction. Instead, Log Manager 9 joins to the S DOBJ_INST table 63 to determine 
the visibility of check docking objects. 

As discussed earlier, the tog manager uses two types of visibility rules, which 
can be summarized as SQL rules and Check-docking-object rules. An SQL rule is an 

20 SQL fragment that expresses whether the docking object instance is visible. An 
example of a visibility condition specified by an SQL rule for the opportunity docking 
object is "An Opportunity is visible if the sales rep is on the sales team." A check- 
docking-object rule indicates that a docking object instance is visible if another 
docking object is visible. The definition of a check-docking-objea rule contains a 

25 SQL fragment that tells the Log Manager how to get all the check docking objects for 
the docking object mstnnre An example of avisibiKty conditicm specified by a c±eck- 
docking-object rule for the opportunity docking object is 9 An Opportunity is viable 
if the Opportunity is used by a Quote that is visible to the sales rep/ 

30 SQL rules are relatively inexpensive in execution resources. In contrast, 

Checkniocking-object rules consume more resources and are therefore more 
expensive. Inord^toexecuteacheck-doddng-object rule, Log Manager recursively 
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runs visibility SQL statements for the docking object it is checking. Determining 
visibility of a transaction can require running hundreds, or even thousands of SQL 
statements. Some objects may have eight to ten check-docking-object rules. Running 
all the visibility rule SQL statements for these objects could take between 0.25 
5 seconds and several seconds for each mobile client As die number of mobile clients 
increases, this can lead to undesirably low levels of service. 

Log Manager also uses the S_DOBJ_INST table to track whether a docking 
object instance (e.g., a particular Opportunity instance) has been downloaded to a 
10 mobile client. The S_DOBJ_INST table prevents Log Manager from downloading a 
docking object instance that was already previously downloaded, or removing a 
docking object instance that was already previously removed. 

The viability cache is implemented in two ways. First, the S_DOBJJNST 
15 table is used for transactions on non-visibility event tables. When checking visibility 
of a transaction, if die transaction is cm a table that does not cause visibility events 
(SJX>BJ_TBLVB_HVTJFLG = then the S_DOBJ_INST table is used to 
determine if the docking object instance is viable. If the docking object instance of 
the transaction exists in the S_DOBJJNST table, then the transaction is visible to the 
20 mobile client Otherwise, the transaction is not viable to the mobile client. The 
benefit is that the Log Manager does not need to run any viability SQL rules or 
check-docking-object rules to determine die visibility. 

Second, die S_DOBJ_INST table is used to determine visibility of check- 
25 docking-objects. Most of the check-docking-object rules may be converted to SQL 
rules that join the check-docking object to the S_DORJ_INST table. If any check- 
docking object exists in the S_DOBJ_INST table, then the check-docking object must 
be visible to the mobile client The benefit is that the Log Manager runs at roost one 
SQL s tatement to determine visibility of a check-docking object. 

30 
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The following example shows the benefits of the visibility cache. Without the 
visibility cache, the set of roles used to check visibility of a docking object 
representing an account might be expressed as the following four rules. 

5 Rule 1 (SQL): Account is visible if Account is a competitor 
primaryjable.<3tfPT_FLG = TT 

Rule 2 (SQL): Account is visible to sales rep if sales rep is on the Account Team: 

exists (select f X' from S_ACCNTPOSTN ap, S_EMPPOSTN ep 
10 where ap.OU_EXTJD = primary _tableJtOW_ID 

and ep.EMPID = :person_id) 

Rule 3 (Check-Docking-Object) : Account is visible if it is an account for an 

Opportunity that is viable: 

15 select OPTYJD from S_OFIY_ORG oo 

where OUID = :primary_row_id 

Rule 4 (Check-Docking-Object) : Account is visible if it is an account for a Quote that 
is visible: 

20 select ROWJD from S_DOC_QU0TE 

where OUID = rprimary^rowjd 

To check the visibility of an Account docking obj ect without a visibility cache t 
25 Log Manager performs the following steps to generate and execute SQL statements 
based on the above visibility rules. 

Step 1: OR together the SQL rules and execute the result: 



30 select '3T from S_ORG_EXT primary jable 

where primary _table.ROW_ID = :primaryjteble_n>w_jd 
and ((primaiy^table.CMFT FLG - TT) 

or exists (select 'X* from Sj\CXOT_POSTN ap, S_EMP_POSTN 

ep 

35 where ap.OU_EXTID = primary jablcROWJD 

and epJBMPJD - :person id) 

) 
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Step 2: Execute Role 3, the check-docking-object rule for the Opportunities object: 

select OPTYJD from S_OFIY_ORG oo 
where OIMD = :primaryjow_id 

5 

For each opportunity retrieved, execute the visibility rule SQL statements 
(SQL rules and check docking object cules) to determine whether the opportunity is 
visible. This can be many SQL statements. 

10 Step 3: Execute the check docking object rule for the Quotes object: 

select ROWJD from S_DOC_QUC3TE 
where OU_ID = :primaryjnow_id 



IS For each quote retrieved, the visibility rule SQL statements (SQL rules and 

check docking object rules) are executed to determine whether the quote is visible. 
This can be many SQL statements. 



The total cumber of SQL statements executed by this process may be 
20 computed as 1 + (Opty Check Objs * Opty vis rules) + (Quote Check Objs * Quote 
vis rules). This may be anywhere from one statement to several hundred statements, 
depending on the number of Opportunity and Quotes objects retrieved. 

With die visibility cache, the set of roles used to check visibility of a docking 
25 object representing an account might be expressed as the following four roles. The 
two SQL roles 1 and 2 are unchanged; the two check-dock-object roles have been 
replaced with SQL roles that interrogate the S_DOBJ JNST table. 



Rule 1 (SQL): Account is visible if Account is a competitor 
30 primary jtabte.CMPT_FLG = TT 

Rule 2 (SQL): Account is viable to sales rep if sales rep is on the Account Team: 

exists (select 'X' from S_ACCNT_POSTN ap, SJBMPPOSTN ep 
where ap.OUEXTJD = primary jtaMe.ROW_ID 
35 and ep.EMPID = :person_id) 
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Rule 3 (SQL): Account is visible if it is an account for an Opportunity that is visible: 

exists (select f X f from S_OPTY.ORG oo, S.DOBIJNST di 
where oo.OU ID = ."primaryjow.id 

and oo.OFTYJD = cfi.PR.TBL ROW ID 
S and di.DOBJJD = :dobjicfand di.NODE.ID = :nodcdd) 

Rule 4 (SQL): Account is visible if it is an account for a Quote that is visible: 

exists (select 'JT from S.DOC.QUOTE q, S.DOBIJNST di 
where q.OU ID = :primaryjowjd 
10 and q.ROWJD = dLFR.TBL ROW ID 

and di.DORJ ID = rdobjid and dLNODE ID = rnodeid) 



To check the viability of an Account docking object using a visibility cache, 

IS Log Manager generates and executes a single SQL statement derived from the four 

SQL iules. Log manager Ors together all four SQL mles to obtain a single SQL 

rule, as follows: 

select f X* from S.ORG.EXT primary Jable 

where primary_tabte.ROW.ID = rprimaryjablejowjd 
and ((primaiyjabte.C35PT.FLG = *Y*) 

or exists (select *X* firom S.ACCNT.POSIN ap, SJEMPJPOSIN 

where ap.OUJJXTJD = primary.table.ROW.ID 
and ep.EMP ID = :person id) 
or exists (select '1C from S.OFTYORG oo, S.DOBIJNST di 
where oo.OU.ID = rprimaiy.row.id 

and oo.OFTYJD = dLPRJIBL ROWJD 
and di.DORJ.ID = :dobjid and dLNODBJD = :nodeid) 
or exists (select *X* from S.DOC.QUOTE q, S.DOBIJNST di 
where q.OUJD = rprimaryrow jd 

and q.ROWJD = di.PR TBL.ROW ID 
and dLDOBJ ID = :dobjid and dLNODBJD = rnodeid) 

) 

35 This single SQL s tateme nt accomplishes the same result as the potentially 

hundreds of SQL statements that would be required without the visibility cache. 



Because the SQL statements can get very large, it is advisable to establish a 
limit to the number of SQL rules that will be ORed together by Log Manager. This 
40 limit is preferably parameter-driven to pennh ease of customization for a particular 
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configuration. In some implementations, it may be useful to limit the number of 
tables in the SQL statement to about 16. 

The following SQL fragments each provide a mechanism for joining to the 
5 S JX)BJJNST table. The fragment that is best for a particular implementation may 
vary depending on the performance characteristics for that implementation. 

Alternative 1: 

or (exists (select X* from SJ3PTY_ORG oo, S_DOBJ_INST di 
10 where oo.OUJD = :primary_row_id 

and oo.OFIYID = di.FR THL_ROWJD 
and di.DOBJJD = rcheckdobjid 
and di.NODBJD = :nodeid) 

) 



15 



Alternative 2: 



or (exists (select *X* from S JX)RJ JNST di 
where dLDOBJJD = rcheckdobjid 
and di.NODBJD = rnodeid 
20 and di JWJTHLBDWJD in ( 

select OFTYJD from S_OFTY_ORG oo 
where oo.OU ID = :primary_row_Jd)) 

) 

25 Alternative 3: 

or (exists (select OFTYJD from S_OPTY_ORG oo 
where oo.OUJD = :primary_row_id 
and OFTYJD in 

(select PRJIBLROWJD from SJX>RJJNST di 
30 whore di.NODE ID = rnodeid 

and dLDORMD = xbeckdobjid 
and di, STATUS FUG = ivistype)) 

) 

35 The following pseudocode shows the algorithm for the visibility checking 

engine using die visibility cache. The algorithm is documented as four routines, 
denoted as CheckTxnVisibility, CheckObjectVisibility, CheckSqlRule and 
CheckOtherRule. 

40 - Check if a record in the txn log is visible to a LaptopNodeld 
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— Also processes implicit visibility events and related dock objects 

static BOOL OieckTxiiVisibility (LaptupNodeld, Table, Rowld, *peVisible) 

{ 

Find die Table in the Dictionary; 
IF Table not found THEN 

Error T&ble not defined 
END IF; 



- set to not visible by default 
*peVistbte = 'None'; 

FOR all docking objects that the table belongs to LOOP 

- Generate SQL to get Primaryld values of the Docking Object 
GeneratePrimaryldSQL (Table, Rowld, DockingObject); 
FOR each Primaiyld value retrieved LOOP 

— Enhancement 81: use cache for non-visibility events 

— txn is for a table that does not cause visibility 

— events and the txn is not an insert on the dock object's 

— primary table (this is a new dock object instance). 

— Do not need to do visibility calculation. No implicit 

— visibility events and no related dock object processing 
IF Table. vistoQityEventFlag = *N* 

&& not an insert into IX>ckCfejectPriniaryTable THEN 

Find the object instance in the S JX)BJ JNST table 
IF status = 'Full' THEN 

"peVisfele « TuF 
ELSEF status = ^Partial' THEN 

•peVisible = 'Partial* 

•peVisibk = 'None' 
END IF; 
ELSE 

- Must recalculate visibility 
OieckC«gert Visibility (LaptopNodeM, PrimaryTable, 
Primary Rowld, depth = 0, peVisible); 
END IF; 

— Process implicit visflrility events and related dock objects 
ReconrileObjectlnstance (LaptopNodeld, PrimaryTable, 

PrimaiyRowId, &eVts9rie); 

— If we need to process implicit viability events, then 

— continue looping through all docking objects even if we 

— already know that the Txn is viable. 
IF *peVisible in (Tull\ 'Partial') THE N 

IF T^k.visibDityEveatFlag = 'N* THEN 
return TRUE; 
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END IF; 
END IF; 
END LOOP; 
END LOOP; 

return TRUE; 

} 

CheckObi ectVisibilitv 

- Check if a docking object instance is visible to the laptop user. 



BOOL CbeckObjectVisibiliry 

(Nodeld, DObjName, PrimaiyRowId, depth, *pe Visible) 

15 { 

— Algorithm: 

- Check FULL visibility 

- Use SQL Rules ORed together 

— Use Check Dock Object Rules one by one 



- Check PARTIAL visibility (iff depth == 0) 

- Use SQL rules OR-ed together 

- Use Check Dock Object Rules one by one 



- Flush the visibility cache to the S_DOBJ_INST table because 

- die SQL nxles will reference the cache. 

Flush the visibility cache to the S_DOBJ_INST table. 

30 — Object is not viable. 

♦peVisible = None; 

- Check Visibility using SQLRULES ORed together 
CheckSqIRule (Nodeld, DObjName, PrimaiyRowId, peVisible, 

35 depth, UTL_VIS_FULL) ; 

IF "peVisible == im._VBFUiL THEN 
goto done; 

- Check Viability using Check Docking Objects 

40 CfaeckOtheiRule (Nodeld, DObjName, PrimaiyRowId, peVisible, 
depth, UTL_VIS_FULL); 
IF *peVisible = = UTL_VIS_FDLL THEN 
goto done; 

45 IF depth == 0 THEN 

/* Check Visibility using SQLRULES ORed together */ 
CheckSqIRule (Nodeld, DObjName, PrimaiyRowId, peVisible, 
depth, UIL.VBPARTIAL); 
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IF •peVisible = = UTL_VK_PARnAL THEN 

goto done; 

/* Check Visibility using Check Docking Objects */ 
5 CheckOtfaerRule (Nodeld, DObjName, PrimaryRowId, peVisible, 

depth, OTLjaS^PAKIIAL); 
IF "peVisible = = UIL^VIS PARTIAL THEN 

goto done; 
END IF; 

10 

done: 
return TRUE; 

} 

15 CtecKSqtttiile 

BOOL CheckSqlRule (Nodeld, DObjName, PrimaryRowId, peVisible, 
depth, eVbT^pe) 

{ 

20 - Create the SQL statement 

- "SELECT *X* from < Primary Table > pt where 

- pLROWJD = < primary table row id> * 

WHILE (TRUE) LOOP 
25 - Build the SQL statement by ORing the SQL rules together. 

FOR each visibility rule for the Docking Object LOOP 

— Only append SQL statements that match the VisType 

— (Partial or FMI) 

IF RuleType != SQLRule 1 1 RuleLocalFlag != eVisType THEN 
30 continue; 

END IF; 

— Limit number of rules per statement to the one 

— specified in the system preference. 

35 IF numberndesjappended = "LOG: vis rules per Stmt" THEN 

break; 
END IF; 

— Add ° < sql fragment >* to sql statement 
40 Append the SQL rule to die sql statement; 

END LOOP; 

- Run the sql statement 

Run the select SQL statement using PrimaryRowId; 
45 IF any rows returned THEN 

— row is visible 
♦peVisible = eVisType; 
goto done; 
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END IF; 

— Stop if no more rules to run 

IF no more rules to append THEN 
S break; 

END IF; 

END WHILE; 

10 done: 

return TRUE; 

} 

CheckQtheriRufe 

15 

BOOL CheckOtherRule (Nodeld, DObjName, PrimaiyRowId, peVisible, 
depth, eVtfType) 

{ 

- Run check docking object roles 
20 FOR each visibility rule for the Docking Object LOOP 

— Only run sql statements that match the VisType 

— (Partial or Full) 

IF RuleType != OxeckDockOfajectRule 
1 1 RuleLocalFbg !- eVisType THEN 
25 continue; 

END IF; 

Run the PaxameterSQL using PrimaryRowId to get newPrimaiyRowId 
FOR each record retrieved by ParameterSQL LOOP 
30 — recursively check viability 

O*ecld0fcjectVisari% (LaptopNodeld, CheckDObjName, 

newPrirnaryRowId, depth + 1, peViable); 
— Stop as soon as the object is found to be visible! 
IF *peVistt>te in (Tun', TartiaT) THEN 
35 goto done; 

END IF; 
END LOOP; 

done: 

40 return TRUE; 
} 



45 Pm^sftfYisiMUty 

The docking process may be further enhanced by treating object visibility as 
a non-binary condition; that is, providing for an object to have a degree of visibility 
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so that it may be visible in certain contexts and not visible in others. This may be 
provided for by associating a visibility strength with each dock object visibility rule. 
Visibility strength is a positive integer that states how visible a given dock object 
instance is. 

5 

Visibility strength provides an alternative to concepts of fidfy and partially 
visible dock object instances. Rather than specifying visibility as either full or partial, 
visibility strengths allow for an unlimited range of visibility for an object 

10 When a visibility rule passes, die dock object instance receives the visibility 

strength associated with the viability rule. This visibility strength controls two 
aspects. 

The first aspect controlled by visibility strength is the downloading or removal 
IS of member table rows. Each member table also has a visibility strength. Docking 
downloads (or removes) member table rows only if tte dock ot^ea instance visibility 
strength is greater or equal to the member table visibility strength. This aspect may 
be used to limit the number of member table rows replicated to docking clients. For 
example, when an Account is visible due to a Quote, docking should download the 
20 Account header, but does not need to download rows in the Account Notes, Account 
Positions, and other member tables. Log Manager download and removal processing 
is improved because Log Manager can skip downloading and removing certain 
member tables. In addition, docking replicates fewer rows to the docking clients, 
and the docking clients occupy less disk space. 

25 

A second aspect controlled by visibility strength is the downloading or removal 
of related dock object instances. Each related dock object rule also has a visibility 
strength. When a dock object instance is viable, docking downloads (or removes) 
related dock object instances only if the dock object instance visibility strength is 
30 greater or equal to the related dock object rule visibility strength. This aspect may be 
used to follow a subsets of related dock objects depending on the reason why the dock 
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object instance is visible, litis allows docking to follow a subset of related dock 
objects even if a dock object instance is partially viable. 

Visibility strength is implemented by adding new attributes to the repository 
5 dock object table, dock object visibility roles and dock object related dock object 
rules. These new attributes specify the visibility strengths of member tables, visibility 
roles and related dock object rules. 

Each dock object visibility rule has a visibility strength. When a visibility role 
10 passes, the dock object instance's visibility strength is equal to the highest visibility 
strength value of all visibility roles that pass. The dock object instance visibility 
strength specifies which member table rows to replicate to a docking client and which 
related dock object rules to ran. 

IS Check dock object visibility roles also have a check-dock-object visibility 

strength. The check-dock-object visibility strength value specifies that the current 
dock object instance is visible only if the other dock object instance has a visibility 
strength greater than or equal to the check-dock-object visibility strength value. 

20 Visibility strength is indicated by an attribute VIS^STRENGTH that specifies 

the strength of the dock object instance. The semantics of this attribute may vary 

depending on the context of the table in which it appears, as more fully discussed 

herein. VK_STRENGTH may have the following values: ' 

0: not visible 
25 5: partially visible 

10: folly visible 

A number of the tables in the database schema are modified to support the 
30 VE J5TRENGTH attribute. The S_DOCK_TABLE table stores the member tables 
for a docking object Each docking object can have one or more member tables. The 
table contains an additional field, VIS_STRENGTH. VIS_STRENGTH is a numeric 
field containing the minimum visibility strength of the dock object instance for rows 
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in this table to be downloaded. The field has a default value of 5, indicating that 
member table rows are downloaded if the dock object instance is partially visible. 

The SJX)CK_VIS_RULE table stores die visibility rules for a docking object 
5 Each docking object can have one or more visibility rules. Hie table contains an 
additional field, VIS_STRENGTBL VISJSTBBNGTH is a numeric field containing 
the visibility strength of the dock object instance if the rule passes. The field has a 
default value of 5 (partially visible) if PARTIAL = 'y\ and otherwise is set to 10. 
The SJDOCKJVKJRULE table also includes a CHECX_VB_STRENGTH field, 
10 used for check-dock-object rules (i.e.» mles with ruleType = 'C). This value 
represents die minimum visibility strength of the check dock object instance to make 
this visibility rule pass. The field has a default value of 10, requiring the check dock 
object to be fully visible, for ruleType='C\ and is otherwise unused and set to 0. 

IS The SJDOCKJIELpBJ table stores the related dock object rules for a 

docking object Each docking object can have one or more related dock object rules. 
The table contains an additional field, VIS_STRENGTH. VIS_STBENGTH is a 
numeric field containing die minimum visibility strength of the dock object instance 
for Log Manager to run this rule. It has a default value of 10, requiring foil 

20 visibility. The S_DOCK_REL_OBJ table also includes a field 
REL_VB_ST"RENGTH. This field contains a value that is used to provide a 
viability strength value to related dock instances. It has a default value of 5. 

The S_DOCK_INST table is a new table replacing S_DOBJ_INST, and stores 
25 the current visibility strength of a dock object instance for each docking client It has 
die following fields. NODBJDD is a non-null unique key that indicates the docking 
client corresponding to this row. DGCKJD is a non-null unique key that indicates 
the dock object corresponding to this dock object instance. PRJIBL_ROW_ID 
contains a key that is the primary table row id of the dock object instance. 
30 VIS__STRENGTH is a numeric field containing the current visibility strength of the 
dock object instance for the docking client 

The following SQL code may be used to define the SDOCKINST table: 
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create table S_DOCX JNST ( 

NODBJD VARCHAR2(15) NOT NULL, 
DOCK ID VARCHAS2(30) NOT NULL, 
PR TBL ROW_ID VARCHAR2(15) NOT NULL, 
5 VIS STRENGTH NUMBER NOT NULL 

); " 

create unique index S_DOCK INST Ul on S DOCK JNST 

(NODE ID, DOCK ID, PR3BLROW ID, VIS_STRENGTH); 

10 



The S_DCK_TXN_LOG table stores the transactions to route to docking 
clients. The table contains an additional field, VIS JSTRENGTH. VIS_STRENGTH 
15 is a numeric field containing the visibility strength of the table referenced by the 
transaction. This value is deaonnalized by the Log Preprocessor and is used by the 
Log Router. It is only used in implementations using the Oracle™ database. The 
following SQL code may be used to define the S_DCK_TXN_LOG table: 

alter table S_IXX_TXN_LOG add (1BL_VK_STRENGTH NUMBER); 

20 

Log Manager routes a transaction to a docking client only if the dock object 
25 instance visibility strength is greater or equal to the member table visibility strength. 
The Log Preprocessor stores the member table visibility strength as a deaonnalized 
value in the transaction log table. 

When Log Router processes visibility events, visibility mles are executed in 
30 decreasing order of visibility strength until a visibility rule passes. When a viability 
rule passes, the dock object instance receives the visibility strength of the visibility 
iule Oat passes. If no viability rule passes, then die dock object instance gets a 
visibility strength of none (value = 0). After calculating die visibility strength, 
visibility strength of the dock object instance is written to the S_DOCKJNST table, 
35 unless the dock object instance has a visibility strength of 0. 
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When Log Router searches for visible transactions, a transactions is fetched 
only if the S JDOCX JNST table has a visibility strength that is greater than or equal 
to the visibility strength of the transaction log denormalized member table. 

S Log Manager uses the member table* s visibility strength attribute to identify 

member table rows to download or remove: When the visibility strength of a dock 
object instance changes, Log Manager downloads or removes member table rows for 
the dock object instance* If the new visibility strength is greater than the old 
visibility strength, the referenced member table rows have not previously been 

10 downloaded and now should be downloaded. If the new visibility strength is less than 
the old visibility strength, then Log Manager removes member table rows that have 
previously been downloaded and should not now be downloaded. 

When processing related dock object rules, Log Manager uses the visibility 
15 strength attribute of each rule to identify which related dock object rules to execute. 
When the visibility strength of a dock object does not change and the visibility 
strength is not None, Log Manager checks related dock object instances and verifies 
that their visibility strength have not changed. When the visibility strength of a dock 
object instance changes, Log Manager checks all related dock object instances and 
20 downloads or removes related dock object instances as needed. If the new visibility 
strength is greater than the old visibility strength, Log Manager executes die related 
dock object rules that have not previously been run and now should be run. If the 
new visibility strength is less than the old visibility strength, Log Manager executes 
the related dock object rules that have been previously run and now should not be 
25 run. 

Log Manager uses the relVisStrength attribute of each rule to reduce visibility 
checking. If the new visibility strength is greater than or equal to the old visibility 
strength, and Log Manager finds a related dock object instance and the related dock 
30 object's relVisStrength is greater than or equal to the other dock object's maximum 
visibility rule visStrength, then Log Manager does not need to re-check visibility of 
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other dock object instance. The related dock object instance visStreagth is set to the 
related dock object's relVisStrength. 

SimnKficd Docking Visibility Rules 
5 The utility of the present invention may be made more useful by simplifying 

the docking visibility rules. Specifically, the docking visibility rules may be stored 
in a single location, the central dictionary, so that the database extraction process 
DBXtract and Log Manager can rely on the same definitions to extract and route 
transactions to mobile clients. Predefined docking visibility rules may also be 
10 provided to support commonly required visibility tasks such as position dependencies, 
employee dependencies, and check-dock-object rules. This approach provides several 
benefits. 

First, storing all docking visibility rules in the central dictionary lets both Log 

IS Manager and DBXtract use the same definitions to route transactions to mobile 
clients, reducing the cost of maintaining docking visibility rules. This also eliminates 
die need to r™»nt»in DBXtract SQL script s for each different database vendor (eg. 
Sybase" 1 , Grade™, or Informix 1 "). Second, it permits the definition of pre-defined 
visibility rules commonly used by vendor-supplied applications. These rules make 

20 it unnecessary to enter SQL fragments or define related docking object rules. 90% 
of all docking visibility rules for typical applications may use pre-defined visibility 
roles. Third, the central dictionary lets customers use the Docking Object List view 
to easily customize docking visibility rules to satisfy site-specific requirements. 
Customers can also easily activate or deactivate visibility rules by changing an 

25 attribute of a viability rule. With simplified visibility rules, clients, such as end 
users, can change visibility rules using an easy-to-use graphical user interface. This 
improves performance for majority of customers by letting us define specialized 
visibility rules for a small set of customers as inactive rules and letting the customers 
activate the specialized rules. Customers that do not use the specialized rules do not 

30 incur the performance cost of the specialized rules. Fourth, storing all docking 
viability rules in a unified location makes it easier to build future docking 
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Simplified docking roles are implemented as follows. Five new types of 
visibility rules are defined ami stored in the central dictionary. 

1) Check-dock-object rules relate two docking object instance to each other 
without the use of a SQL fragment. Check dock object rules are similar to SQL rules 

S except that a check dock object definition between two docking objects is stored 
instead of a SQL fragment. For example, an opportunity is visible if an activity that 
is fully visible uses die opportunity. 

2) Position rules specify that a docking object instance is visible if an 
employee on the docking client occupies a position for the docking object For 

10 example, an opp o rtun ity is visible if an employee on the docking client is an 
opportunity sales team member. 

3) Position manager rules specify that the docking object instance is visible if 
an employee on the docking client is the manager of an employee that occupies a 
position for the docking object For example, an opportunity is visible if an employee 

IS on the docking client is the manager of an opportunity sales team member. 

4) Employee rules specify that a docking object instance is visible if an 
employee on the docking client is assigned to the docking object For example, an 
activity is visible if an employee on the docking client is assigned to the activity. 
Employee rules are typically used for owner, creator, etc. 

20 5) Employee manager rules specify that the docking object instance is visible 

if an employee on the docking client is the manager of an employee assigned to the 
docking object For example, an activity is viable if an employee on die docking 
client is the manager of an employee assigned to the activity. Employee manager 
rules axe typically used for manager of owner, manager of creator, etc. 

25 

In Log Manager, visibility SQL statements are generated from the central 
dictionary at runtime. Code is added to the visibility checker common AH to 
generate and run SQL st atem en ts for the new visibility rule types. Log Manager's 
visibility event code is modified to use the new types of visibility rules to find related 
30 docking object instances. 
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Fig. 9 depicts a database diagram for the central dictionary. This diagram is 
akin to the schema of Fig. 2 with addft ipn qi sipport added to the 
SJXXX_VE_RUUB table, as follows. 

5 The S_DOCK_VIS _RULB table contains the visibility rules associated with 

a particular Docking Object SJDOCX_VIS_RULB 71 contains the additional fields 
DOCKJD, SEQUENCE, TYPE, ACTIVE and PARTIAL. Field DOCKJD 
identifies the Docking Object with which a particular visibility rule is associated, 
referred to as the •current docking object/ Field SEQUENCE is a sequence number 

10 that indicates the sequence, relative to other visibility rules in the table, in which the 
particular visibility rule should be run. The ACTIVE field indicates whether a 
particular rule is active or not A value of TT or null indicates that the rule is active, 
and a value of f N* indicates that it is inactive. The field TYPE specifies the type of 
the particular visibility rule. A value of 'S* indicates an SQL rule; a value 'O' 

IS indicates a parameter dock object rule; a value »C* indicates a check-dock-object rule; 
a value *P* indicates a position rule; a value 'Q* indicates a position manager rule; 
a value *E* indicates an employee rule; a value *F indicates an employee manager 
rub. The field PARTIAL, if set to *Y\ indicates that if the visibility rule is 
satisfied, the current docking object is partially visible. If set to *N* or null, it 

20 indicates that if the visibility rote is satisfied, the current docking object instance is 
folly visible. 

In addition the S_DOCK_VIS JKULB table contains a number of fields whose 
meaning and meaningfoiness depends upon the rule type. 

25 

SQL rules use the fields SQLSTATEMENT and VEJ5VT_COLS. In this 
context, the SQLJSTATMENT field is an SQL fragment that, if it returns any rows, 
indicates that the dock object instance is visible. 

30 Parameter Dock Object Rules use the fields CHECKDOCKTD and 

SQL_STATMENT. In this context, CHECK_DOCK_ID contains a pointer to another 
docking object and SQL_STATEMENT contains an SQL statement to obtain the 



-48- 



WO 98/38583 



PCT/US98/03573 



PrimarylD values for the other dock object For each PrimaiylD retrieved, Log 
Manager runs the visibility rule of the other dock object 

Check-Dock-Object rules use the fields CBECK_DOCK_ID, 
5 SRC_COLUMN_ID and TAR_COLUMN_ID. In this context SRC^COLUMN^ID 
identifies the column in the current dock object that joins to the check dock object and 
TAR_COLUMN_ID identifies the column in the check dock object that joins to the 
dock object join column. For the Check-Dock-Object type, the visibility event 
columns is implicit' all columns needed to join from the primaiy table of the current 
10 dock object to the dock object join column. 

Position rules use the field PQSTN_COLUMN_ID> which is a column in a 
member of table of die current dock object that points to the S_POSTN table. For 
Position rules, the visibility event columns is implicit all columns needed to join 
IS from the primary table of the current dock object to the position column. 

Position Manager rules use the field POSTNjCOLDMNJD, which is a 
column in a member of table of the current dock object that points to the S w POSTN 
table. For Position Manager rules, the visibility event columns is implicit: all columns 
20 needed to join from the primary table of the current dock object to the position 
column. 

Employee rules use the field EMPjCOLUMNJD to identify a column in a 
member table of the current dock object that points to the S_EMPLOYEE table. For 
25 Employee rules, the visibility event columns are implicit all columns needed to join 
from the primary table of the current dock object to the employee column. 

Employee Manager rules use the field EMP_COUJMNID to identify a 
column in a member table of the current dock object that points to the S_POSTN 
30 table. For Employee Manager rules, the visibility event columns is implicit all 
columns needed to join from the primary table of the current dock object to the 
employee column. 
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SQL statements are stored in the central dictionary memory structures for 
access by Log Manager and DBXtracL When the dictionary is loaded, SQL 
statements axe generated and stored in the memory structures. Because die number 
of SQL statements are small, the generation code is expected to take less than one 
5 second. Alternatively, if the generation takes too long, the dictionary API may be 
modified to generate the SQL statements for a given dock object whenever the dock 
object is first referenced. 

Appendix B describes the format SQL statements that Log Manager and 
10 DBXtract generate at runtime and provide an example of these SQL statements using 
the Accounts dock object 

CONCLUSION 

Various modifications to these embodiments will be readily apparent to 
IS those skilled in the art, and the generic principles defined herein may be applied to 
other embodiments without the use of inventive faculty. Thus, the present 
invention is not intended to be limited to die embodiments shown herein, but is to 
be accorded the widest scope consistent with the principles and novel features 
disclosed herein. 

20 All publications and patent applications mentioned in this specification are 

herein incorporated by reference to the same extent as if each individual 
publication or patent application was specifically and individually indicated to be 
incorporated by reference. 

The invention now being folly described, it will be apparent to one of 
25 ordinary skin in the art that many changes and modifications can be made thereto 
without departing therefrom. 
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APPENDIX A 



Writing User Transaction Log File for a Given Laptop Node 



This program will be called by a server-side process that processes transaction log 
5 entries for all Laptop Nodes. For each Laptop Node, the calling process building the 
UserTrxnLogFfleName and calling Program 1. 

Input Parameters 

• LaptopNodeld - nodejd of the destination laptop 

10 • UserTxnLogFiJeName - full path of the file where txns will be written 

• MaxBatchTxns - number of txns between commits and updates to the 
SJ>OCK_STATUS table 

• MaxTxns - number of txns to process in this session. Use this parameter to 
limit processing. 

IS Main Algorithm 

Check parameters 
IP (MaxTxns < 1 1 1 MaxBatchTxns < l) THEN 
Invalid Parameter 
20 BHD IF 

Get last LOGJEXTRACT Timber for the Laptop from SJDOCK_STATUS 
Iast_txn_cnwni t_number = OTLDStatGetLogNum (LaptopNodeld) ; 

25 Initialize Variables 

Bunftans *> 0; Total number of txns processed 

BumBatchfrxnB « 0; Total number of txns written in the current 

batch 

30 Read Docking Object and Table definitions into memory structures 

StartDictApi (); 



35 



50 



Open the User Log Txn file 
Open User Log Txn file 

-- Select and process new txns in S_ttXKjrRAHSACTIOH_LOG 

where txn_cx»uit_number > las t_txn_co5nni t_nuober 
FOR each new txn LOOP 



40 Stop processing if reac h MnxTxnB 

IF HumXxns = MaxTxns THEB 
break ; 



45 Prevent circular txns. Do not send the txn back to the 

originating laptop 

IF txn . OriginHodeld » Lap t opcode Id THBH 

Goto next transaction 
BHD IF; 



Process all other types of transactions 
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This is the visibility calculator) 

This routine also processes implicit visibility events 

Later: Data Merge can call this function to check whether a txn 

is 

5 still visible when merging txns into a laptop or server 

database. 

GheckVisibility (LaptopHodeld, LogRecordType # TableBame, 

TransRowId) ; 

IP txn is visible tHBH 
10 Write transactions to UserTxnLog file depending on the 

type of LogRecordType. 
Write the txn to the user log file 
++HuaBatchTxns 
BHD IF; 

15 

Finished processing the txn 

Commit (if needed) 

IF BumBatchTxns » HaxBatchTxns THBH 

Assume that separate process comes around and deletes 
20 Txns in 3_DOOTjniAHSACTION_L0G that have been processed 

for all nodes . So , no need to delete the txns from the log. 
Update last LOG_EXTRACT number for Laptop in SJDOCK_STAXUS 
Commit; ~ 
HumBatcbTxns = 0 
25 BHD IF; 

++NumTxns 

Bad Loop; /* Bach transaction in the Txn Log table */ 

30 Commit 

Update last LOG_EXTRACT number for Laptop in S_DOCK_STATUS 
Commit ; 

Close log file (if need ed) 
35 IF UserTxnLogFileP 1* HULL THBH 
dose File; 
BSD IF; 

StopDictApi () ; 

40 

Check Viability Routines 



Chedc if a record in the txn log is visible to a LaptopHodeld 
BOOL GheckVisibility (LaptopBodeld, LogRecordType , TableHame, 
45 TransRowId) 

-- SQLStatements routed based on the dest ination list 
IF LogRecordType in CSQLStatement' ) THBH 
IF Laptop Node in destination list THBH 
50 return THUS; 

BHD IF; 

Shadow and Multi Record LogRecordTypes are routed to all nodes 
--Ho visibility events with these LogRecordTypes* 
55 BLSIF LogRecordType in ('ShadowOperation' , ' Mul tiRecordDele te ' , 

'ImoltiRecordDpdate' ) THBH 

return THDB; 

Simple Deletes need more processing 
60 BLSIF LogRecordType in ('Simple Delete') THBH 

IF (tabl e .vis ibility in {'Enterprise' , 'Limited')) THBH 

_r etura TRDB; 
BHD IF; 
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Single Inserts and Simple Updates need more processing 
CheckXxnVisibilityt) also processes illicit visibilit y even ts 
ELS IP LogRecordType in ('Sinple Insert' , 'S imple Update') THEN 
IF (tabl e .vis ibility = 'Enterprise') THEH 
5 return TRDB; 

ELSIP table. visibility = 'Limited' THEN 

IP CheckT xriVi sibility (LaptopHodeld, Table, Rowld) THEN 

return TRDB; 
BHD IF; 
10 BHD IF; 

BSD IF; 

) 

Check if a record in the txn log is visible to a LaptopNodeld 
IS static BOOL QxeckTxnVisibility (LaptopKodeld, Table, Rowld) 

BOOL bVisible « FALSE; 

Find the Table in the Dictionary; 
20 IF Table not found THEH 

Error: Table not defined 
BHD IF; 

FOR all docking objects that the table belongs to LOOP 
25 Generate SQL to get Primaryld values of the Docking Object 

GenerateFrimaryldSQL (Table, Rowld, DockingObject) ; 
FOR each Primaryld value retrieved LOOP 

CheckObjectVisibility (LaptopHodeld, PrimaryTable, 
PrimaryRovId) 
30 IF Object is visible THEN 

Because CheckObjectVisibility () also processes implicit 
visibility events, we must loop through ALL docking 

objects 

even if we already know that the Txn is visible. 
35 Exception: if the table has VTS_event_FLG = 'H' 

then we can return immediately. 
IF Table . visib ilityBventFLO « 'B' THEH 
return TRDB; 

40 bVisible = TRDB; 

BHD IF; 
BHD IF; 
BHD LOOP; 
BHD LOOP; 

45 

return bVisible; 

} 



50 Check if an instance of a docking object is visible to the laptop 

user. 

Also processes implicit visibility events 1 
BOOL CheckObjectVisibility (LaptopHodeld, DockingObj ect Name , 
PrimaryRowId) 
55 { 

FOR each visibility rul e for the Docking Object LOOP 
IF RuleType = RuleSQL THEH 

Run the select SQL s tateme nt using PrimaryRowId; 
IF any rows returned THEH 
60 row is visible 

-- Process an implicit Download Object 

Downl oadObject Instance (LaptopHodeld, PrimaryTableHame, 

PrimaryRowId) ; 

return TRDB; 
65 BHD IF; 

ELSIF RuleType « CheckDockingObject THEH 

Run the ParameterSQL using PrimaryRowId to get newPrimaryRowId 
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FOR each record retrieved by ParameterSQL LOOP 
BBCORSIVBI 

CheckQbj ectVisibility (LaptcpNodeld, CheckDocXingObj ectHame , 

newPrimaryRovId) ; 

5 IFrc a TRUE THEN 

ProceBB an implicit Download Object 
DoimloadObj ectlnstance (LaptopNodsId, PrimaryTableHaae, 

PrimaryRowId) ; 

return TRUE; 
10 BSD IF; 

BSD LOOP; 
BHD IP; 
BHD LOOP; 

15 Object is not visible. 

Process an i implicit Remove Object 
RemoveQb j ect Instance ( LaptopHodeld , PrimaryTableKame, 
PrimaryRowId) ; 

20 

return FALSE; 

} 



25 



55 



Generate SQL Statement to Get Primaryld 

Generate the SELECT SQL statement to get the Primaryld value of 
~- the docking object for the given MemberTable 



SQL s tate ment looks lilce: 
30 SELECT tp.<xx?w_id> 

PROS <tableJ5wner> . <Table> tl f 

<table_owner> . <PKTable> t2, 

... one or more intermediate tables between the table 
and the PrimaryTable 
35 <table_owner> . <PKTable> tH 

<table_owner> . <PrimaryTable> tp 

WHBRB tl.ROW_ID a :rov_id /* row_id in transaction log */ 

/* join to PK table t2 */ 

ABD tl . <FXOolumn> = t2 . <PKColumn> 
40 ASD <tl FKOonditian> 

/* any number of joins until reach the table that joins 
to the PrimaryTable */ 

/* join from t2 to tH */ 

ASD t2 . <FKC6lumn> = tH . <PKColumn> 
45 ASD <t2 FRCondition> 

/* join to t he PrimaryTable */ 

AHD tH.<FKColumn> » tp , <PKColinnn> 

ABD <tH FKConditicn> 

50 -- Bote that there may be one or more paths from the Member Table. 

to the Primary Table. We need to generate a SQL select statement 
for each of the paths and UNION the statements together. 



This function assumes that there are no loops in the definition. 

These SQL statement do not change for each Table in a Docking 
Object, 

so we can calculate them one and store them in memory. 



60 struct 

CHAR* selectList; 
CHAR* f romClause ; 
CHAR* whereClause; 
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DINT numTables; /* also the number of joint to reach the Primary 
Table */ 
) GenStmt; 



GeneratePrimaryldSQL (Table, DockingObject) 

/* there may be more than one SQL statement, so we have a dynamic 
array of SQL statements. Bach element in the array is a path ' 
10 from the Table to the Primary Table*/ 

DynArrld GenStmtArr; 
GenStmt newGenStmt; 



15 



25 



CHAR* sqlStmt; 
DynArrCreate (GenStmtArr) ; 



Create the first element and initialise 
newGenStmt » mallocO ; 
20 newGenStmt .numTables - 1; 

newGenStmt. selectList = "SELECT rov_id a ; 
newGenStmt . f romClause « ' FROM <Table> tl"; 
newGenStmt . vhereClause = »WHKRB tl.ROW_ID » :rov_id"; 
DynArrAppend (GenStmtArr, NevGenStmt) ; 



/+ Recursively follow FKs to the PrimaryTable */ 

Build the select, from and where clause simultaneously */ 
AddPKTable (Table, DockingObject, GenStmtArr, 0) ; 



30 Onion all the paths together 

numS easts e DynArrSize (GenStmtArr) ; 
FOR all elements in the array LOOP 

tmpSqlStmt = GenStmtArr E j ] . selectList 1 1 GenStmtArr [ j ) . f romClause 
1 1 GenStmtArr [j ] . whereClause ; 

35 sqlStmt » sqlStmt 1 1 'UNIGH' j | tmpSqlStmt; 

BSD LOOP; 

DynArrDestroy (GenStmtArr) ; 

40 IP sqlStmt = BOLL THEN 

Error: no path from Table to Primary Table* 
BSD IF; 

} 

45 

-- Recursively follow all FKs to the Primary Table 
AddPKTable (Table, DockingObject, GenStmt, Inputs tmtltum) 

DIRT mimFKS - 0; 
50 OTNT Stmt Kim; 

GenStmt newGenStmt; 

FOR all FKs for the table LOOP 

17 PKTable is a Member Table of the Docking Object TBEB 
55 If there's more than one FK, then there is more than one 

path 

out of the current table. 

Copy the S QL stm t to a new DynArrBlmt to create a new path 
IF mimFKs > 0 TBBH 
60 -- Create a new element and copy from GenStmt [ Inputs tmttfum] 

newGenStmt « mallocO; 

newGenStmt . numTables » GenStmt [InputStmtBum) .numTables; 
newGenStmt. selectList o GenStmt flnputStmtRum] .selectList; 
newGenStmt. £ romClause = GenStmt ( InputStmtBum) .f romClause; 
65 newGenStmt .whereClause a GenStmt [InputStmtBum] .whereClause; 

DynArrAppend (GenStmtArr, &newGenStmt) ; 
StmtHum s DynArrSize (GenStmtArr) ; 
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Put a check here for infinite loops 
IP StXBtBum as 20 THEN 

Error: Probably got an Infinite loop? 
BHD IP? 
5 ELSE 

StmtHum o inputStmtHum; 
END IP; 

Append the new PKTable to the fromdause and whereClause 
10 GenStfflt [StmtRum] . fromClause = 

GenStnrt [StmtNum] . f rcmClause | | • # \n <Table> t<nunfTables ♦ 

l>"r 

GenStmt [StmtNum] .whereClause » 

GenStmt (StmtBum) .whereclause 1 1 
IS "JU3D t<nu»Table8> . <FKColumzi> = t<numTables ♦ 

l>.<PRColumn>" | | 

■JUSD <FKCondition for Table if any>"; 
4-tGenStmt .nuntTables; 

20 PICTable is the Primary Table then Done. 

IP PICTable m PrimaryTable THEN 

RETURN; 
ELSE 

AddPKTable (PKTable, DocXingObject, GenStmt, StmtNum) ; 
25 END IP; 

-- only count PKs to other member tables in the same Docking 

Object 

++numPKs; 



30 



END IP; 
BHD LOOP; 



RETORB; 

35 } 



Process Visibility Events 



Download an Object instance to a Laptop 

This function also downloads all Related Docking Object instances. 
40 BOOEL DownloadObj ectlns tance (LaptqpNodeld, ObjectName, PrimaryRowId) 

^ -- Check if the object instance is alre ady downloaded to the laptop 
Find the object inst ance in the S_DGQBJ_INST table 
IP exists on laptop THEN 
45 return TKOGB; 

BHD IP; 

Register object instance in S_DOBJJCHST table 

50 Write Download Object records to the Tarn Log 

FOR each member table of the docking object LOOP 
Generate SQL select statement to download records 
write each retrieved record to the User Txn Log file 

BHD LOOT; 

55 

Download records for Parent Object instances 
FOR each RelatedDockingObject LOOP 

Run ParazaeterSQL to get newPrimaryld of RelatedDockingObjects 
FOR each newPrimaryld retrieved LOOP 
60 -- Qierfc if the instance of the object is visible to the laptop 

user 

CheckObjectVisibility (LaptopNodeld, ObjectName, PrimaryRowId) 
IP visible THEN 

Down! oartObjectTTiBtanpe (LaptopNodeld, 
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RelatedDockingObject , 

newPrimaxyRovId) ; 
BHD IF; 
BHD LOOP; 
5 BHD LOOP; 

return TBDB; 

} 

10 

~- Remove an Object Instance to a Laptop 

This function also removes all Related Docking Object instances. 
BOOL RemoveObject Instance (LaptopNodeld, QbjectName, PrimaryRowId) 

15 -- Check if the object instance is already downloaded to the laptop 

Find the object instance in the S_DCEBJ_I13SX table 
IF does not ex ist on laptop THEN ~~ 

return TRDR; 
HND IF; 



20 



Delete the object instance from S_DQBJ_INST table 



-- Write Remove Object records to the Txn Log 
FOR each member table of the docking object LOOP 
25 Generate SQL select statement to get records to delete 

Write each retrieved record to the User Txn Log file 
BHD LOOP; 

Remove for Parent Object instances 
30 FOR each RelatedDockingObject LOOP 

Run ParameterSQL to get newPrimaryld of RelatedDockingObject 8 
FOR each newPrimaryld retrieved LOOP 

-- Check if the instance of the object is visible to the laptop 

user 

35 CheckOb j ectVisi bilit y (LaptopSodeld, ObjectHame, PrimaryRowId) 
IF not -visible TURN * 
RemoveObj ect Instance (LaptopSodeld , 

RelatedDockingObject, newPrimaryRowId) ; 

BSD IP; 
40 BHD LOOP; 

BSD LOOP; 



45 



return TRDB; 
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Appendix B: SQL Statements and Examptes 
Top Level SQL Sta te m en t s 

This section describes the format SQL sfatrrarnts thai Log Manager and DBXtract generates at 
runtime. See the next section for an example of these SQL st a t emen t s using the Accounts dock 
5 object. 



Log Manager WsB&ty SQL Statements 

Log Manager grrmrafes visibility sql statements when checking the visibility of a dock object 
insta n ce. Log Manager grrtrmtra a <sab sql statement > for each visibility rule, the structure of 
which depends on the visibility rule type (see Sub SQL Statement* below). 

10 

select 'X' 

from &Table_Owner . <primary table> primary table 
where primary_table . ROW_ID - <primary_row_Td> 
and ((<sub sql statement> 1) 
IS OR (<sub sql statement 2>) 

OR (<sub sql statement N>) 

) 

/ 

20 Log Manager Rotated Dock Object SQL Statements 

Log Manager grnffrntes related dock object sql ftfnttmtnrs after the visibility of a dock object 
instance has changed. Log Manager generates one or more <sub sql statements > for each 
visibility rule, the structure of which depends on the visibility rule type (see Sub SQL Statements 
below). 

25 

<sub sql statement> 
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Sub-Statements for SQL Rules 

Log Manager VtsJbB/ty SQL Statements 

<sql fragment > 

5 Log Manager Related Dock Object SQL Statements 

User enters related dock object sql statements. 
act Phase 2 SQL Statements 

select. DISTINCT pt.ROW_ID ITEM_IDjr, <dobj_id> 

ITEM_TYPE_T , 

:node_id CREATED_B Y JT , cpartial f lag> 
PARTIAL_FLGjr 

from : table_ovner . <primary_table> pt 
where <sql f ragmen t> 
and pt-ROW_ID not in 

(select di.ITEM_ID 

from :table_owner,S_DCK_INIT_ITEM di 
where di * CREATED_B Y = :node_id 
and dl.ITEM TYPE « <dobj id>) 

/ 



DBXtn 

10 
15 
20 
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Sub-Statements for Check Dock Object Rules 
Log Manager V&bBity SQL Statements 

SQL Stitemtal Template 

5 exists (select 'C* 

from &Tables 

&Table_Owner.S_DOBJ_INST di 
where di.NODE_ID « :node_id 

and di.DOBJ_n> =» &Chec)c_IX)bj_Id 
10 and di . STAT_FLG « 'P' 

and di . PR_TBL_ROW_ID = &Join_Column 
&Joins " 

/ 

IS Algorithm 

Build source and target dock object paths separately. Join source path to source primary table, 
Join target path to SJDOBMNST table. Then join source and target using the two join columns, 

Build Source object paths 
20 IP source join column table » source primary table 

THEN 

— can optimize: join target object directly to 
primary table 

&Tables : add nothing 
25 &Joins : add nothing 

pSrcJoinCol » "prima ry_table . csource join column> n 
ELSE 

Get paths from source join column table to source 
primary table. 

30 - The paths will not include the source primary table 

- The paths will not include the source join column 
ftTables: Add every table in path to from clause, last 

flffflnnt fi,TT»fr: 

• 6Table_Owner.<pathcol [N] ->pTable->pTableName> 

35 sN» 

&Joinst 

* Add joins for all path cols except the last 
element : 

•and sN.<pathcol[N] ->pColtimnName> = sN+l.ROW_ID" 
40 - Add join from last element to primary rowid: 

"and s<last>.<pathcol [last] - >pColumnName> « 
primary^ table • row_xd " 

pSrcJoinCol - "sl.<source join column>" 
END IF 

45 

l. Build Target object paths 

IP target join column » target primary table R0W_ID 
THEN 

can optimize: join source object directly to 
50 SJDOBJJNST table 

feTables : add nothing 
&Joins : add nothing 
pTar JoinColumn : nothing 
&Join_Column: pSrcJoinColumn 
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ELSE 

Get paths f ran target join column table to target 
primary table. 

- The path will not include the target primary table 
5 if the path traverses 

any other member table. 

- The paths will not include the target join column. 
&Tables: Add every table in path, first element first 

"&Tables_Owner . <pathcol [N] - >pTable- >pTableName> 

10 tN" 

&Joins: 

- Add joins for all path cols except the last 
element: 

"and tN+i.ROW_XD = tN.pathcol [N] ->pColumnName° 
IS (note backwards order) 

pTarJoinColumn: "tl.<Target join column> B 
&Join_Column: ° t<last> . <pathcol [last] - >pColumnName> ■ 
END IP 

20 2. Join source and target join columns 

fcJoins : Add join from target join column to source / 
join column if both exist: 

"and <pTarJoinColuxnn> = <pSrcJoinColumn>° 

25 3. Replace CTables, &Join_Column and &Joins in the SQL 
statement template . 

TWwpU 1: Opportunity visible due to Activity 

30 Source Object = Opportunity (src ptable: SJDPTY) 

Target Object - Activity (tar ptable: SJSVT_ACT) 
Source join column = S_0PTY . R0W_ID 
Target join column = S_EVT_ACT.OPTY_ID 

35 1. Target Path: S_EVTACT.ROW_ID 

&Tables : S_EVT_ACT tl 

&Joins : and di.PRJIBL_ROW_ID - tl.ROWJID 
pTarJoinCol : tl . 0PTY_ID 

2. Source Path: S_OPTY.ROW_ID 
40 fiTables: add nothing 

fiJoins : add nothing 
pSrcJoinCol: primary_table.ROW_ID 

3. Join source and target 

&Joins : and tl.OPTY ID = primary table. ROW ID 

45 

select 'X' 

from &Table_Owner . S_OPTY prima ry_table 
where R0W_ID = ? 

and exists (select 'C 
50 from &Table_Owner.S_EVT_ACT tl, 

&Table_Owner . SJX>B J_INST di 
where di*NGDB_ID - :node_id 

and di.DOBJJED » &Ckeck_D0bj_Id 
and di.STATJPLG = 'F' 
55 and di.PR TBL ROW ID » tl.ROW ID 
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10 



and tl.OPTY_ID - 
primary_table . R0W_ID) 

Rmwpto Activity viable due to Opportunity 

Source Object = Activity (src ptable: S_EVT_ACT) 

Target Object => Opportunity (tar ptable: SjOPTY) 

Source join column = S_EVT_ACT.OPTY_ID ~ 
Target join column « S_OPTY*ROW_ID 



1. Target Path: S_OPTY\ROW ID 

fcTables: S_OPTY tl 

&Joins : add nothing 

pTaraJoinCol : di . PR_JTBL_ROW_ID 
15 2. Source Path: SJSVT_ACT.ROW_ID 

&Tables : add nothing 

&Joins : add nothing 

pSrcJoinCol : primary_table . OPTY_ID 
3. Join source and target 
20 fcJoins: and di.PR_TBL_ROW_ID » 

primary_table • OPTY_ID 

select 'X' 

from &Table_Owner . S_EVT_ACT pr i ma ry__t able 
25 where ROWJED » ? 

and exists (select 'C 

from &Table_Owner.S_OPTY tl, 

&Table_Owner.S_DOBJ_INST di 
where di.NODB_n> « :node_id 
30 and di.DOBJ_ID - &CheckJ)Obj_Id 

and di.STAT_FLG = 'F' 
and di.PRJTBL_ROW_ID « 
primary_table . OPTY_ID) 
/ 



35 



Example 3: Account visible due to Partner Account 



Source Object: Account (src ptable: S_ORG_KXT) 
Target Object: Account (tar ptable: S_ORG_EXT) 
40 Src join column: S_ORG_EXT . R0W_ID 

Tar join column: S_ORG_RBL.PRTOR_OU_n> 

!• Target Path: S_ORG_RBL.OU_ID 
arables: S_0RG_REL tl 
45 feloins: and di . PR_TBL_ROW_ID - tl.0U_ID 

pTar JoinCol : tl.PRTOR_OU_ID 

2. Source Path: S_0RG_EXT . ROW_ID 
&Tables: add nothing 

&Joins : add nothing 
50 pSrcJoinCol: primary_table.ROW_ID 

3. Join source and target 

&Joins: and 1 1 . PRTOR_OU_ID = pr i ma ry_tabl e » ROW_ID 

exists (select 9 C 
55 from &Table_Owner . S_0RGJ£BL tl. 
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&Table_Owner*S_DOBJ_INST di 
where di.NODE_ID - :node_id 

and di.DOBJJD = &Check_IX)bj_Id 
and di.STATJ?LG » 'F' 
5 and di . PR_TBL_ROW_ID = tl.OU_ID 

and tl.PRTNR_0U_3D - 
primary table. ROWJED) 
/ 

10 Example 4: Account visible due to Parent Account 

Source Object: Account (arc p table: S_ORG_KXT) 
Target Object; Account (tar ptable: S_ORG_EXT) 
Src join column: S_ORG_BXT . R0W_ID 
15 Tar join column: S_ORG_EXT-PARENT_OU_ID 

1. Target Path: S_ORG_BXT.ROW_ID 
&Tables: S_ORG_EXT tl 

fcJoins : and di . PR JTBL_ROW_ID = tl.ROW_ID 
20 pTar JoinCol : tl.PARKNT_OU_ID 

2. Source Path: S_ORG_EXT.ROW_ID 
^Tables: add nothing 

&Joins : add nothing 
pSrcJoinCol: primary_table.ROW_ID 
25 3. Join source and target 

&Joins: and tl.PARENT_OU_ID « primary_table.ROW_ID 

exists (select *C 

from &Table_Owner.S_ORG_EXT tl, 
30 &Tabl e_Owner . SJX>BJ_INST di 

where di . N0DB_ID - :node_id 

and di.DOBJ_ID = &Check_DObj_Id 
and di . STAT_FLG « 'F' 
and di*PRJTBL_ROW_ID = tl.ROW ID 
35 and tl . PARENT_OUJED = 

primary_table . RCW_ID) 
/ 



3 . Log Manager Related Dock Object SQL Statements 

40 

SQL Statement Template 

select pt.ROW_3D 
from fcTables 
45 &Joins 
/ 

Algorithm 

Build source and target dock object paths separately. Join target path Id :primary_row_id. 
50 lorn source sod target using the two join columns. Get source primary table ROW_ID 

1. Build Target object paths 

IP target join column » target primary table ROWJED 
THEN 
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can optimize: join source object directly to 
: pr imary_row_id 
&Tables: add nothing 
&Jolns : add nothing 
5 pTarJoinColunm « 0 :primary__row_id° 

ELSE 

Get paths from target join column table to target 
primary table. 

- The paths will not include the target primary table 
10 if the path traverses 

any other member table. 

- The paths will not include the target join column. 
&Tables: Add every table in path last element first 

• &Table_Owner . <pathcol [N] - >pTable- >pTableName> tN" 

15 &Joins : 

- Add join from :primary_row_id to last path 
column: 

" and tclast>.<pathcol [0] ->pColumnName> « 
: primary_row_id 0 
20 - Add joins for all path cols except the last 

element: 

"and tN+l.ROW_ID = tN.<pathcol[Nl - 
>pColumnName> n (note backwards order) 

pTar J oinColunm : B tl.<Target join column> n 
25 END IF 

2. Build Source object paths 

Always add source primary table in join to guarantee 
that the source dock object instance exists 
30 IF source join column table « source primary table 

THEN 

optimize: can omit source tables from SQL 
statement 

&Tables : "<source primary table> pt" 
35 &Joins : add nothing 

pSrcJoinCol: "pt.orc join column>° 
ELSE 

Get paths from source join column table to source 
primary table. 

40 - The paths will not include the source primary table 

- The paths will not include the source join column 
fcTables : 

- Add every table in path to from clause, first 
element first : 

45 ° &Table_Owner „ <pathcol [N] ->pTable- 

>pTableName > sN° 

- Add source primary table to from clause: 

•&Table_Owner.< source primary table> pt* 

&Joins 

50 - Add joins for all path cols except the last 

element: 

"and sN.<pathcol[N] - >pColumnName> = 
BN+LROWJED" 

- Add join from last element to source primary table 
55 row id: 



-64- 



• WO 98/38583 



PCT/US98/03573 



°and s<last>.pathcol [last] - >pColumnName «■ 

pt.ROW_ID D 

pSrcJoinCol = °sl*<Source join column>° 
END IF 

5 

3. Join source and target join columns 

&Joins: Add join from target join column to source join 
column; 

"and <pTar J o inCol > ~ <pSrcJoinCol>° 

10 

Example 1: Opry risible due to Activity (Get all Opportunities for an Activity) 

Source Object = Opportunity (src ptable: S_0PTY) 
Target Object = Activity (tar ptable: S_EVT_ACT) 
15 Source join column - S_OPTY.ROWjn> 

Target join column - S_EVT_ACT . 0PTY_ID 

1. Source Path: S_OPTY . ROW_ID 
^Tables: S_OPTY pt 

20 &Joins : add nothing 

pSrcJoinCol: pt ♦ 0PTY_ID 

2. Target Path: S_EVT ACT.ROWJTD 
fcTables : S_EVT_ACT tf 

&Joins : and :primary_row_id - tl.ROW_ID 
25 pTar JoinCol : tl.OPTY_ID 

3. Join source and target 

fcJoins : and tl.OPTY_ID = pt.ROWJTD 

select pt.ROW_3D 
30 from &Table_Owner . S_EVT_ACT tl, 

&Table_Owner . S_OPTY pt 
where : pr i ma ry_row_id = tl.ROWMOD 
and tl.OFTY_ID - pt.ROW_n> 

/ 



35 



Example 2; Activity viable due to Opportunity (Get all Activities for an O pp ort uni ty) 



Source Object = Activity (src ptable: S_EVT_ACT) 
Target Object « Opportunity (tar ptable: S_OPTY) 
40 Source join column = S_EVT_ACT . OPTY_ID 

Target join column = S_OPTY . ROW_ID 

1. Source Path: S_BVT_ACT.ROW_ID 
&Tables: S_EVT_ACT pt 

45 &Joins : add nothing 

pSrcJoinCol: pt,OPTY_n> 

2. Target Path: S_OPTY.ROW_ID 
&Tables: add nothing " 
&Joins : add nothing 

50 pTar JoinCol : : primary_row_id 

3. Join source and target 

&Joins : and tl-0PTY_ID = pt.ROW_ID 

select pt.R0W_ID 
55 from &Table_Owner . S_EVT_ACT pt 
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where :primary_row_id = pt . OPTY_ID 
Fjmmpfe 3: Account visible doe to ftarteer Account (Get all Accounts for a partner Account) 

5 

Source Object: Account (src ptable: S_ORG_EXT) 
Target Object: Account (tar ptable: S_ORG_EXT) 
Src join column: S_ORG_BXT.R0W_ID 
Tar join column: SjORG REL.PRTNR OU ID 

10 

1. Source Path: S_ORG_EXT . ROW_ID 
&Tables: S_ORG_EXT pt 
&Joins : add nothing 
pSrcJoinCol: pt,ROW_JDD 
15 2. Target Path: S_ORG_REL.OU_ID 

&Tablea : S_ORG_REL tl 

&Joins : and :primary_row_id ° tl.OTJ_ID 
pTarJoinCol : tl . PRTNR_OU_ID 
3. Join Bource and target 
20 &Joins : and tl.PRTNR_OU_ID - pt.ROVTJED 

select pt.ROWJED 

from &Table_Owner.S_ORG_REL tl, 
&Table_Owner.S_ORGJBXT pt 
25 where : primary_row_id - tl.OUJED 

and tl.PRTNR_OU_ID » pt.ROW_ID 

Fremplr 4: Account risible due to Parent Account (Get all Accounts for a Iferent Account) 

30 

Source Object: Account (src ptable: S_ORG_EXT) 
Target Object: Account (tsar ptable: S_ORG_EXT) 
Src join column: S_ORGJB3CI\ROW_ID 
Tar join column: S ORG EXT. PARENT 017 ID 
35 ~ 

1. Source Path: Sj0RG_EXT.ROW_ID 

&Tables: s_org_ext pt 

&Joins : add nothing 

pSrcJoinCol: pt.ROW_ID 
40 2, Target Path: S_ORG_EXT.ROW_ID 

&Tables: SJDRGJSXT tl 

&Joins : and : primary_row_id « tl.ROW_ID 
pTarJoinCol : tl.PARENT_OU_ID 
3. Join source and target 
45 fiJoins: and tl * PARENT_OU_ID « pt.ROW_ID 

select pt .ROW_ID 

from &TablejOwner.S_ORGJSXT tl, 
&Tablej0wner.S_ORG_EXT pt 
50 where : pr imary_row_id = tl.ROWJED 

and tl.PARERT_OU ID - pt.ROWJED 
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Sub-Statements for Position Rules 
Log Manager Visibility SQL Statements 
SQL StatpmpTrt Template 

5 

exists (select 'X' 

from ^Tables 

&Table_pwner.S_EMP_POSTN ep, 
&Table_Owner.S_NODE BMP ne, 
10 &Table_Owner • S_NODE~REL nr 

where nr.N0DE_ID = : node_id 

and nr.SUB_NODE_ID = ne.N0DE_ID 
and ne.EMP_ID » ep.EMPJED 
and ep-POSITION_ID » &Join_Column 
IS ficJoins) 
/ 

Algorithm 

Build paths. Join path to primary_taMe.ROW_IEl Join position column to position labia 

20 

IF position column table » primary table 
THEN 

-- can optimize: join prima ry_table directly to 
S_EMP_POSTN 
25 ficTables: add nothing 
&Joins : add nothing 

&Join_Column: "primary_table > <position column>" 
BLSB 

Get paths from position column table to primary table. 
30 - The paths will not include the primary table 

- The paths will not include the position column 
^Tables Clause: 

- Add every table in path, last element first 

*&Table_Owner.<pathcol [N] ->pTable->pTableName> 

35 jN* 

&Joins Clause: 

- Add joins for all path cols except the last element: 

■and jN. <pathcol [N] - >pColumnName> » jN+l.ROW_ID 0 

- Add join from last element to primary rowid: 

40 "and j<last>.<pathcol [last] ->pColumnName> - 

primary_table . ROW_ID » 

&join_Column: » jl.cposition column>" 
BHD IP 

45 Replace &Tables, &Join_Column and &Joins in the SQL 
statement template. 

Example 1: Opportunity ftaftkm 

50 Object: Opportunity (primary table: SjOPTY) 

Position Column: S OPTY_POSTN . P0STN_ID 
Path Cols: S JDPTY_POSTN . 0PTY_ID 
&Tables: S_OPTY_POSTN jl 

&Joins: and jl*OPTY_ID « priinary_table.ROW_n> 
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&Join_Coluinn: j 1 . POSTN_H> 

exists (select 'X' 

from &Table_Owner.S - OPTY_POSTN jl, 
5 &Table_Owner . S_EMP_POSTO ep, 

&Table_Owner . S~NODE_aiP ne, 
CTable_Owner.S_NODB RBL nr 
where nr.N0DB_ID » :node_Td 

and nr.SUB_NODE_ID = ne,NODB_ID 
10 and ne.EMP_ID = ep.BMP_ID 

and ep. POSITIONED = jl.POSTN_ID 

and jl.OPTY ID « primary table. ROW ID) 

/ 

15 Example 2: Quote Ftehion 

Object: Quote (ptable: SJX>C_QUOTB) 
Position Column: S_DOCJ}UOTE . POSTNJE) 
Path: S_DOC_QUOTB.ROW_ID 
20 fcTables : none 

&Joins: none 

&Join_Column: primary_table . POSTN_ID 

exists (select 'X' 
25 from &T&ble_Owner.S_EMP_POSTN ep, 

&Table_Owner „ S_NODB_RBL nr, 
&Table_Owner.S_NODE_EMP ne 
where nr.NODE_ID * :node_id 

and nr . SUB_NODB_ID « ne.N0DB_ID 
30 and ne*BMP_ID * ep . BMP_ID 

and ep . POS ITI0N_ID = 
primary table. POSTN ID) 
/ 

Log Manager Related Dock Object SQL Statements 

35 

SQL St ateo ect Templates 
Node to Curat Dock Object 

select pt.ROWJlD 
40 from &Table_Owner.S_NODB_REL join_table # 

&Table_Owner . S_N0DB_EMP ne, 
&Table_Owner.S~EMP_P0STN ep r 
arables 

where join_table.NODE_ID = :node_id 
45 and join_table.NODB_ID = :primary_row_id 

and j ©instable ♦STOJK)DE_ID « ne.N0DB_ID 
and ne.EMP_ID = ep7EMP_ID 
and ep . POSITI0N_ID « &Join_Column 
&Joins 

50 / 
Algorithm 
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Build paths. Join path to pLR0W_IU Join position cohxnm to position table. Always join to 
primary table so (be statement only retains related objects that really oust ILg. only retrieve 
Opportunities that re&Dy exist* 

5 IP position column table » primary table 
THEN 

can optimize: join prima ry_table directly to 
S_EMP_POSTN 

&Tables: <prixnary table> pt 
10 &Joins: enrpty 

&Join_Column: •pt.<position columns* 0 
ELSE 

Get paths from position column table to primary table. 

- The paths will not include the primary table 
IS - The paths will not include the position column 

feTables Clause: 

- Add every table in path first element first 

" &Table_Owner . <pathcol [N] ->pTable- >pTableName>" 

- Add primary table: <primary table> pt 
20 &Joins Clause: 

- Add joins for all path cols except the last element: 

"and jN.<pathcol[N] - >pColuranName> - jN+l.ROW_ID" 

- Add join from last element to primary rowid: 

"and j<last>.<pathcol [last] ->pColumnName> = 
25 pt.ROW_ID» 

&Join_Column: *j Imposition column> B 
END IF 

Replace ^Tables , &Join_Column and foJoins in the SQL 
30 statement template. 

Fi ample 1: Opportunity Ito lt io n 

Object: Opportunity (p table: S_0PTY) 
35 Position Column: Sj0PTY_POSTO.POSTNJCD 

Path: S_OPTY_POSTN . OPTY_ID 
^Tables: S_0PTY_POSTO jl, S_0PTY pt 
&joins : and jl.0PTY_ED = pt .R0W_ID 
&Join__Column: : jl.POSTN ID 

40 

select pt.ROWJED 

from &Tablej0wner.S_NODE H RSL join_table, 
&Table^Owner . S_N0DB_EMP ne, 
&Table_Owner „ S_EMP_POSTN ep, 
45 &Table_Owner . S_0PTY J?OSTN jl, 

&Table_Owner . S_0PTY pt 
where join_table.N0DE_n> = :node_id 

and j oin_table . N0DE_n> = : pri rria ry_row_id 
and j oin_table . SUB_N0DE_ID = ne . N0DE__ID 
50 and ne.EMPJED = ep.EMP_ID ~~ 

and ep.POSrnON_3D = j 1 . P0STN_ID 
and jl.OPTY ID = pt.ROW ID) 

/ 

55 
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Example!: Quote Fbshkm 

Object: Quote (p table: S_DOC_QUOTE) 
Position Column: S_DOC_QUOTE . POSTN_ID 
5 Path: S_D0C_QU0TE.R0W_ID 

&Tables : S_D0C_QU0TB pt 
&Joins : none 
&Join_Column: pt . POSTN_ID 

10 select pt.ROHLID 

from &Table_Owner.S_N0DE_REL joinj:able, 
&Table_Ovmer.S~N0DE_EMP ne, ~ 
&Table_Owner.S_EMP_POSTN ep, 
&Table__Owner . S_DOC_QUOTB pt 
15 where join_table,N0DB_ID « :node_id 

and j oin_table . N0DB__ID - : primary_row_id 
and j oin_taJole . SUB_NODE_ID « ne.NDDE_XD 
and ne.EMP _ID ° ep7EMP_ID 
and ep - POSnTON_ID » pt-POSTN ID) 

20 / 
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Sub-Statements for Position Manager Rules 
Log Manager Vhibffity SQL Statements 
SQL Statement Ifcaoplate 

5 

exists 



10 



15 



/ 

20 Algorithm 

Same as Position Rule algorithm* except we use the SQL statement template above. 

Log Manager Related Dock Object SQL Statements 

SQL Statement ThnpUrra 
25 Node to Current Dock Object 

select pt»ROW_3D 

from &Table_Owner . S_N0DE_REL join_table, 
&Table_Owner.S N0DB__EMP ne, 
30 aVTable_Owxier.S~EMP_POSTN ep, 

&Table_Owner . S_POSTN_RPT_RBL prr 
&Tables 

where join_table.NODB_ID = :node_id 

and join_table.NODB_ID = : primary_row_id 
35 and join_table*SUB_NODE_ID » ne.N0DE_ID 

and ne*EMP_ID =• ep.EMP_ID 
and ep.POSITION^ID = prr.POSITION_ID 
and prr.SUB_POSTN_ID = &Join_Colu£n 
&joins 

40 / 

• Employee to Current Dock Object 
select pt.R0W__ID 

45 to A*RWo_OwnerS_NODB_REL fit 

XUb^JCHnxxSJiODB EMPm. 
Alkhfe OwnuS EMP POSTN ejv 
ftlkbfe.OmxS.FOOTH mjtEL pir 

50 wbe» mJ«ODE JD = :nod»Jd 

cod m£UB_NODEJD - o&NOBBJD 
tad oclEMPJD «= tpJEMPJD 
tad epk£MP_ID = • f K uiw y j tmJd 

ud tpjt)smoN_iD «=■ pnj*0QmoN_n> 



(select 'X' 
from tTables 

&Table_Owner . S_POSTN_RPT_REL prr, 
&T&ble~Owner.S_EMP_POSTN ep, 
&Table_Owner . S_NODB_EMP ne, 
&Table_Owner . S_N0DE~REL nr 
where nr.NODB_n> = : node_id 

and nr . SUB_NODE_ID = ne.NODB_n> 

and ne.EMP_ID » ep.EMP_ID 

and ep.POSITIONJED = prr.P0SITI0N_ID 
and prr . SUB_POSTN_ID «= &Join_Colinnn 
&Joins) 
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cod pfi£UB_FOSnt_ID =» &Jaxn_Cofcxma 
AUd 

/ 



S * ftxsition to Current Dock Object 



select pt*ROW_ID 

tan Alkblc_OwoetS_NODB_REL a; 
AUbfe OwwcS NODE EMPoo. 
10 ATabaTowM^EMPjoSTNerv 

&7afoks 

wbe» nrNODEJD :mfojd 
ml iaSUB_NODE_ID «=> li^NODBJD 
15 ud otvEMPJD ■» cpvEfttPJD 

and cp^POSmON_ID = rfwinmyjwjd 

and jota jabJe. POSfTK>N_n> - :prin»*y_io»_id It bdp ^haao by providing whie 
and jciD_tiblcLSUB_POSrN_n) » AMajCokmn 




Algorithm 

Same as (bsition Rule algorithm, except we create related dock objects from Nodes* Employees; 
Positions and use the SQL rtatrmrnt trmpfatrai above. 
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Sub-Statements for Employee Rules 
Log Manager VistbSty SQL Statements 

SQL Statement lexnplatB 

5 

exists (select 'X* 

from &Tables 

&Table_Owner.S_NODB_EMP ne, 
&Table_Owner.S_NODE_RBL nr 
10 where nr * N0DE_H> = :node_id 

and nr • STJB_NQDE_ID » ne.NODB_ID 
and ne . EMP_ID - &J oin_Colunm 
&Joins) 

/ 

15 

Algorithm 

Sum as Position Rule algorithm, except wb use the SQL statwnrnt trgnplntn above. 

Log Manager Related Dock Object SQL Statements 

20 SQL Statement Templates 

Node to Current Dock Object 

select pt.ROW_ID 

from &Table_Owner.S_NODE_REL join_table, 
&Table_Owner . S_NODB_EMP ne 
^Tables 

where join_table.NODB_ID = :node_id 

and join - table.NGDE_ID » :primary_row_id 
and join_table.SUB_NODB_ID ° ne.NODE_ID 
and ne.EMP_n> = &Join_Column 
&7oins 

/ 

Algorithm 

35 Same as Rk&oq Rule algorithm, except we use the SQL •***— trmpfatn abewe. 



25 
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Sub-Statements for Employee Manager Rules 
Log Manager Visibility SQL Statements 

SQL Statement Template 

5 

exists 



10 



15 



20 / 
Algorithm 

Same as Position Rule algorithm, except we use the SQL statement template abew. 
Log Manager Related Dock Object SQL Statements 

25 

SQL Statnnrut Templates 
Node to Current Dock Object 

select: pt*ROW_ID 

from fcTable_Owner.S_NODB_REL join_table, 
&Table_Owner . S~NODE_EMP ne, 
&Table_Owner . S_EMP_POSTN pmgr, 
&TablejO*mer*S_POSTN_RPT_RKL prr, 
&T&blej0wner.S_BMP_POSTN psub 
^Tables 

where j oin_table . NODE_ID « :node_id 

and join_table.NODB_ID « :primary_row_id 
and j oin_table . SUB_NODB_ID « ne.NODE_ID 
and ne.EMP_ID = pmgr .EMP_ID 
and pmgr . PO SITI0N_ID « prr.POSITION_ID 
and prr.SOT_PQSTNJID » psub . POSITION_ID 
and psub.EMP_ID = &Join_Column 
&Jolns 

/ 

• Employee to Current Dock Object 
select pt.R0W_ID 

to&WoOwDeES NODE RELu, 
50 &rnbk».O«riMxS_H0DB_BMP ftt, 

A£Dbl»_Ovnc£S_EMP_POSnf pari* 
ATkb4e_O«riietS_P0SrNJRFr_RHL pn. 



(select 'X' 
from &Tables 

&Table_Owner.S_BMP_POSTN psub, 
&TSable_Owner.S_POSTN_RPT_REL prr f 
&T&ble_Owner.S~EMP_POSTN pmgr, 
&Table_Ovner . S_N0DB_EMP ne, 
&Tabl e_Owner . S_N0DB RBL nr 
where nr*NODB_ID =» :node_Td 

and nr . SUB_NODB_ID = ne.NODBJID 
and ne.EMP_lD » pmgr.EMPJE) 
and pmgr-POSITION_ID - prr . POSITION_ID 
and prr . SUB_POSTN_ID - psub.POSITION_ID 
and psub.EMP_n> « &Join_Column 
fiJoins) 



30 



35 



40 
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wane hkNODBJD =» raodojd 
tad oxSUB_NODB_ED =» oewNODBJD 
tad o&EMFJD » innjT.ffMPJP 
•ad psgLEMP_ID *=* 41c lnuwy_ftwrjkJ 
•ad psBRtPOSITION^ID » pTT.POS!TTON_n> 
•ad prtSUB_POSTN_ID «=* psuKFOSJTlONJD 
•ad pnto>EMP ID » Alois fWnmif 



10 



Rostt&oii to Current Dock Object 



select pt.ROW_ID 

IS fixn AH^J>mtSJ90mjtEL at 

ATttto_OwnetS_IOfirfH_RPT_REL joio tabic, 
tflfefe 0*ne*S EMP POSTN pa*r 

20 

wbe»a*NODE ID- aod* id 
•ad dkSUB.NODB.ID - a&NODEJD 
tod ot^EMPJD ™ paig&EMFJD 
tad pcn^POSmON_ID = ^rinnyjRwjd 
25 tnd jota_ttble.POSrnON_ID — :ptmitiy_io»Jd // hdp lybnc by prorating whw 

tad jott~t*le^UB JOOTNJD « pssbJOSniON ID 

ftJoira 

30 

Algorithm 

Same as Fixation Rule algorithm, accept we create related dock objects from Nodes, Employees, 
ftosmons and use the SQL statranrnt tempfotra above. 



35 
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Example 

Hoe are *»»mpH of visibility roles for the Account docking object and sql statrmrnts that Log 
Manager and DBXtract generate for e&ch visibility role. 



Visibility Rules for Organization 



< 


TEE" 
# 


Ue 
Type 


Partial 

R>s 


ftJoWnt 


Check 
Object 


Check Dock 
Object Source 
Coknao 


Toe? Dock Object 
Target CebjBm 




Emp 
Col 






N 


LC » V 












2 


PoUtlCA 


N 










s accnt post 
n" 

rosmoN id 




3 


r 


N 










SJMLCJSXt 

PRJWTNJD 




1( 


T — 


Check 

Dock 

Object 


Y 




Cestac 
t 


S.ORGJEXT 

sown) 


S.CoftfACi 1 

fr_diotjoimd 






"5 


Check 
Dock 
Object 






t 


rowjd 


5KROTCHUM 

T 

ou n> 






6 


Check 

Dock 

Object 


V 




Accom 
t 


S ORG EXT 
ROWJD 


SOkCkEL 

PRTNR OU ID 







Rule Descriptions 

IS 1. Rule 1: Account is a competitor 

2. Ride 2: Saks rep b tm tb* account team 

3. Rule 3: Manager of the u f uaaiy sales rep on the Account 

4» Rule 4: ftiuuury Amain! for a Conrart yon have TWMIffy on 

5w Rate 5; Secondary Artortnt fox a Contact you bare full visibifity on 

20 6. Rule 6: Account for a partner Account you bare full risibility on 

6. Log Manager \fisB>&ty SQL Statements 

Log Manager runs the role sql siafrpjrulw OR-ed to gether: 



select 'X' 

25 frcan &Table_Owner . <primary table> primary_table 

where primary_table . ROW_ID = <prinary_rcw_id> // 
rule 1 

and ( (primary_table • CMPT_FLG « 'Y') 

OR (exists (select 'X' // 

30 rule 2 

from &Table jOwner . S_NODE_REL 

nr, 

&Table_Owner . SJNODBJBMP 

ne, 

35 &Table_Owner • S_EMP_PQSTN 

ep, 

&Table_Owner . S J&CCNT_POSTN jl 

where nr.NODE_ID « ;node_id 
40 and nr . SUB_NQDB_ID » 

ne.KODKJED 

and ne.EMP_ID ° ep . EMP_ID 
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and ep . POSITION_ID o 

ji.posrnoN_n> 

and jl.OU_n> = 

primary_table . ROW_JD) 
5 OR (exists (select 'X' // rule 

3 

from &Table_Owner.SJNODE_RBI# 

nr, 

&Table_Owner . S_NODB_BMP 

10 ne, 

&Table_Owner . S_BMP_POSTN 

ep, 

&Table__ Owner. S_POSTN_RPT_RBL prr 
15 where nr . NODE_ID = :node_id 

and nr*SUB_NODE_ID « 

ne.NODE_ID 

and ne . EMP_ID =» ep.EMP_n> 
and ep.POSITION_ID - 

20 prr . POSITION_ID 

and prr.SDB_POSTN__ID - 
primary_t able . PR_POSTN_ID ) 

OR (exists (select 'C // rule 

4 

25 from &Tablej0wner.S_D0BJ_IN3T 

di, 

&Table_Owner*S_CONTACT tl 
where di.NODE_3D = :node_id 

and di.DOBJ_ID - <Contact Dock 

30 Object Id> 

and di.STAT_FLG « 'F' 
and di.PR_TBL_ROW_ID » tl.ROW_ID 
and tl.PRJ>BPT_OU_ID ° 
primary table. ROW_ID) 
35 OR (exiBtB (select 'C // 

rule 5 

from &Table_Owner.SJK)BJ_INST 

di, 

&Table_Owner . S_PBR_ORG_UIsliT tl 
40 where di.N0DE_ID ■* :node_id 

and di.DOBJ_3D = <Contact Dock 

Object Id> 

and di.STAT_FLG = 'P' 
and di.PRJIBL ROW_ID - tl.PERJE) 
45 and tl.OU_ID « 

primary_table . ROW_ID) 

OR (exists (select 'C // 
rule 6 

from &TablejOwner.S DOBJ INST 
50 di, ~ 

&Table_Owner.S_ORG_REL tl 
where di.N0DB_ID = 7node_id 

and di.DOBJ_ID « <Account Dock 

Object Id> 

55 and di . STAT PLG « f P' 
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and di ♦ PR_TBL_ROW 3D 

tl.OU_ID 

and tl.PRTNR_OU_n> » 
primary_table . ROW_ID) 
) 

/ 



Log Manager Related Dock Object SQL Statements 

• Nodes 

10 

select pt.ROWJED // rule 2 

fim £X«bte_arar^_NODB_RELjoin, 

ATtbkTorar.S EMPPOSTNcp, 
15 ATtbk~OtmBr^lACCKr_POarmjl. 

ATabW.OwMr^.ORO.EXrpI 
when joio_^teJtODl_ID - rnocWM 
tad job tabfcJIODEJD = rpnm§jy_row_id 
«dJo>ajAle^UB_rN»»n>» oe.NODBJD 
20 and ntwEMP ID « cp-EMFJD 

tad cp JOSmON.ID - jl-POSmONJD 

and ji.ouu> - ptJtowjD 

/ 

25 ■efactptJtOWJD //rob 3 

from ATabW.Oiwr^ JK>DE Jl£L Jmn^tibW, 

AXafefo Owner J_POaTN_RPT_RELprr. 
30 ATfcblTOwDfct^ORO^BCrpt" 
wbcnjotejafcfeNODEJD = :nod»U 
«nd jotojablCkNODE ID » :ptnmiy_nrtr_id 
«aljoiftJablfcStm_NOD£jn>» neJIODBJD 
rad ntvEMPJD ■* «*J3tlPJD 
35 and ep-POSTTJONJOD » pfT-POSmONID 

and prr.SUB_P03TN_n> Q pLHt_FOOTN_ID 

/ 

• Employees 

40 

select pt.ROWMOD // rule 3 

from ATafcle_OwncT.S_N01>E_REL m. 
AT«bk>_Oworr-S_KODE_aiP oe. 

45 dkTattaTo««JSJWni JUTRELsrr. 

ATabaToiw^ OTO JHXT pt 
wtmarJIODB ID « nodnjd 
«ad or JStm JIODBJD » oewNODBJD 
and mJSMPJD — cp.EMP_n> 
50 tad cpJEb&JD » ftiiaaiyjrowjd 

sod cpJOSmON_ID «=» ptr JOSJTTON^ID 
and prr.SUB_POSTN_[D « pt. PR^POSTTMD 

/ 
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select pt.ROW_ID // rule 3 

5 froco &T«bte_Owoer.S_KODB_RELfir, 

AT«bto__OwDcr^KODE_EMPi», 

OTabJe~OwDcr^F08TKJtiTJtELj^ 
jmbfe'oww^ORO.Errpt 
10 wbw» v JtODEJD « 3>od»Jd 

■ad ».SUB_NODBJD «= no^NODEJD 
«nd noJJMPJD « cp£MPJD 
■ad ep.POSmONJD = ^tsamiyjemja 
and join tobfe. POSITION ID =* ,pi timu j_rcHr id 
15 «ndjda~tabk^UB POSTN ID-pt.PR POSTN ID 

/ 



20 



25 



30 



select pt.ROW_XD 

fan &TdbfejO«ra£_CONTACrt1, 
AT«hte_Owner^WU3_EJCT0 
whsn rpranuy row id- UJtOWJD 
*odtl.PR D£FT OU ID-ptJtOWJD 



sekctpUtOWJD 
from AT«Me_OirMr3 w PEftjC»lO_UNrrU, 

«r^j5«fo>r^oRO_scrpi 

where :prim*iy_mirjd — tlJEMD 
•sdti.OD.ID - pUtOWJD 



// rule 4 



//tub 5 



35 * Accounts 

select pt.ROWJLD // rule 6 

from ATable J>wmx^ JDfcO JtEL tl , 
OT»Me Oww^ ORQ EXT pt 
whom juhuuy _nmj& » tl jOUJD 
40 ■aStiJBSNBjOU.IDoptJtOW.ID 

; 
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CLAIMS 



10 



1. A method of managing a database, said database including a central 
database (3) and separate partially replicated databases (23a, 23b, 23c), 
said separate partially replicated databases (23a, 23b, 23c) residing at 
separate nodes (21a, 21b, 21c), each of said partially replicated databases 
(23a, 23b, 23c) having an associated visibility strength, comprising 
determining the visibility strength of a partially replicated database (23a, 
23b, 23c) to data being propagated, and propagating said data to the 
partially replicated database (23a, 23b, 23c) only if the partially replicated 
database (23a, 23b, 23c) has visibility to the data. 

2. An article of manufacture comprising: 

a computer usable medium having computer readable program code 
means embodied therein for causing determining the visibility 
IS strength of a partially replicated database (23a, 23b, 23c) to data 

being propagated, determining therefrom the visibility of the 
partially replicated database (23a, 23b, 23c) to the data being 
propagated, and propagating said data to a partially replicated 
database (23a, 23b, 23c) only if the partially replicated database 
20 (23a, 23b, 23c) has visibility to the data, the computer readable 

program means in said article of manufacture comprising: 

computer readable program code means for rinsing a 
computer to effect determining the visibility strength 
of a partially replicated database (23a, 23b, 23c) to 
25 data being propagated; 

computer readable program code means for cau si ng a 
computer to effect propagating said data to a partially 
replicated database (23a, 23b, 23c) only if the 
partially replicated database (23a, 23b, 23c) has 
30 visibility to the data. 

3. A program storage device readable by a machine, tangibly 
embodying a program of instructions executable by a machine to 
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perform method steps for managing a database, said method steps 
comprising determining the visibility strength of a partially 
replicated database (23a, 23b, 23c) to data being propagated, 
determining therefrom the visibility of the partially replicated 
database (23a, 23b, 23c) to the data being propagated, and 
propagating said data to a partially replicated database (23a, 23b, 
23c) only if the partially replicated database (23a, 23b, 23c) has 
visibility to the data. 
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